[prev in list] [next in list] [prev in thread] [next in thread] 

List:       webkit-dev
Subject:    [webkit-dev] Platform.h vs. makefiles
From:       Darin Adler <darin () apple ! com>
Date:       2020-05-11 0:13:08
Message-ID: 70E10E86-6C32-45A0-84CF-ECEE5C1DE86B () apple ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]