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
> On May 10, 2020, at 5:13 PM, Darin Adler 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
> 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
> 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
> 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
> 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 mailing list