> On Oct 20, 2020, at 2:25 PM, Keith Rollin <krol...@apple.com> wrote:
>> On Oct 20, 2020, at 10:51, Andy Estes <aes...@apple.com> wrote:
>>> On Oct 18, 2020, at 11:01, Sam Weinig <wei...@apple.com> wrote:
>>> One direct benefit of moving away from DerivedSources.make would likely be 
>>> (I say likely, as the details of how it works out are far from certain in 
>>> my mind) removing at least one place that a IDL file needs to be listed as 
>>> we would not need to explicitly the list the IDL file in 
>>> DerivedSources.make, and would only need to ensure it was in some 
>>> *input.xcfilelist.
>> The way I imagine this working is that the existing .idl file references in 
>> the (e.g., WebCore) project would become members in a target with a custom 
>> build rule for “*.idl”. Target membership is itself another list inside the 
>> .xcodeproj file, just one you manage through checkboxes in Xcode (and can be 
>> done reasonably quickly as part of adding a new file reference).
>> Whether or not this actually creates one fewer “place a IDL file needs to be 
>> listed” (which I think is a worthwhile goal), I think you should still 
>> remove the Makefile build phases from Xcode for the reasons you originally 
>> cited.
>> Andy
> Overall, this sounds like an awesome endeavor. The initial reasons for using 
> Makefiles were sound ones (as Darin described), but there are also the 
> incumbent issues, such as maintainability and efficiency.
> I wasn’t clear on what the alternative to Makefiles would look like, though. 
> The options that occur to me are:
> * Custom build rules, as Andy describes. This seems to make sense, but I 
> wonder if it is flexible enough for all the cases we might want to put it 
> through. Our DerivedSources.make files process many types of files. I haven’t 
> checked, but I could imagine that not all of these files could be uniquely 
> distinguished by their suffixes. That is, there might be one set of *.foo 
> files that should be processed one way, and another set that should processed 
> another way. In those cases, I guess some suffixes could be changed to 
> accommodate the different processing.
> * Using a set of Run Script build phases. That is, have a Run Script phase 
> for processing a specific set of *.idl files, another for processing one set 
> of *.foo files, a third for processing a different specific set of *.foo 
> files, and so on. I’m against this approach, though. While it offers lots of 
> flexibility, it’s not very maintainable. It would mean having to keep the set 
> of script inputs and outputs up-to-date, something that is fragile, even with 
> the help of the generate-xcfilelists utility script.
> Of these two, the one based on custom build rules seems to make the most 
> sense. One need only add a file to an Xcode project and possibly a CMake 
> file. Of note, the dreaded .xcfilelists are not affected (and, if this 
> project can be taken to its extreme, we can get rid of the 
> DerivedSources*.xcfilelist files). I do worry about some efficiency issues, 
> though. For instance, one part of DerivedSources.make processes Platform.h 
> (and all its children) in order to extract some configuration information. 
> That processing is done once per DerivedSources.make invocation. If we move 
> to a model where a script is invoked once per *.idl file, then the overhead 
> is now multiplied by the number of *.idl files. We should watch for that. 
> (Perhaps your recent configuration/preferences/settings changes obviate the 
> need to pre-process Platform.h all the time?)

My thought is that we would be using a combination of Run Script phases and 
Build Rules, depending on the thing being generated. There are quite a few 
one-off scripts like makeprop.pl, makevalues.pl, 
makeSelectorPseudoClassAndCompatibilityElementMap.py, etc, that don’t have 
their input or output change very often at all, so are really much better 
suited for a Run Script phase. Whereas things like the IDLs are better suited 
for build rules.

For the Platform.h issue, I think we could probably engineer things in the 
short term to have a script phase that produces a Defines.txt that the other 
script phases and build rules depend on. Longer term, I would like to remove 
the need for it altogether, but that’s going to take additional work in the 
various scripts.

> Still, I’m open to a solution based on a single IDL.txt file that can be 
> shared by Xcode and CMake. It all depends on the details, the resulting 
> solution, and the trade-offs it makes.
> Regarding Xcode vs. CMake, I certainly understand the reasons people would 
> like to see us move solely to CMake. But, for now, the plan is to see if we 
> can get Apple-OS ports to build with CMake at all. Replacing Xcode and 
> xcodebuild is a follow-on project with an interesting set of issues. I set up 
> #cmake on Slack to provide a place where we can talk about this for anyone 
> who’s interested.

Thanks for the feedback,

- Sam

> — Keith
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
webkit-dev mailing list

Reply via email to