[webkit-dev] Platform.h vs. makefiles

2020-05-10 Thread Darin Adler
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


Re: [webkit-dev] Platform.h vs. makefiles

2020-05-10 Thread Maciej Stachowiak

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