> 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 

* 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?)

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.

— Keith

webkit-dev mailing list

Reply via email to