> 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 webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
