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 

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

webkit-dev mailing list

Reply via email to