I think the best way to configure WebKit is to use a separate data file, neither a header nor a makefile or similar, that defines the options in a single place with clear syntax. Then everything else is generated from that. Such a system could cover runtime flags as well, which are even more scattered around the project than compile-time flags.
Moving logic from build files to the header is probably a move in the right direction, though of course it carries risk, particularly for less tested configurations. - Maciej > On May 10, 2020, at 5:13 PM, Darin Adler <da...@apple.com> wrote: > > Hi folks. > > The Platform.h configuration file family has been useful for WebKit for a > long time. We created it to try to organize configuration options in WebKit > so the would not be spread out through the whole project. > > One way to look at these, particularly the ENABLE options, is as a set of > configuration options that let each consumer of the WebKit source code create > a unique flavor of WebKit with the particular features they want enabled > turned on and others turned off. Another is to think of this as a mechanism > for keeping decisions made by the WebKit contributors organized and easy to > understand. > > If these truly are WebKit consumer options, then it’s important they be set > as part of the build process. The macros can be defined with a build and > configuration system outside WebKit, and the Platform.h headers should > interpret those values correctly. > > On the other hand, if we are just trying to keep our decisions straight, then > it would be best if the logic for what is on and what is off by in the header > files, written with preprocessor macro logic, and not spread across multiple > make files and scripts. > > Thus I think the pattern on macOS, for example, of setting these in .xcconfig > files doesn’t make a lot of sense. I think the .xcconfig files should compute > the things that need to be determined about the build environment, but the > configuration decisions should be in files like PlatformHaveCocoa.h, for > example. > > I think the guideline should be like this: > > All code to compute configuration should be in the Platform.h files, not in > makefiles, with only the following exceptions: > > 1) Options like ENABLE(XXX) that some ports wish to offer as options to > people building WebKit can have overridden values in makefiles. But even > these options should have sensible defaults in the Platform.h headers that > express the current status of the port from the point of view of the port’s > maintainers. Ideally we’d find a way to not repeat these default settings > twice. > > 2) In some cases, the build machinery needs to contribute to things like > feature detection. So on some platforms, things like HAVE(READLINE) would be > set correctly by the build system. > > Options intended to be set by the environment would carefully be wrapped in > #ifndef. > > But other options, which simply express relationships between configuration > elements, are designed to be set by Platform.h and not overridden by the > environment, and so they would not be wrapped in #ifndef. Many HAVE options > and most USE options would fall into this category. > > What do you all think? > > — Darin > _______________________________________________ > webkit-dev mailing list > firstname.lastname@example.org > https://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list email@example.com https://lists.webkit.org/mailman/listinfo/webkit-dev