[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] Platform.h vs. makefiles
From: Maciej Stachowiak <mjs () apple ! com>
Date: 2020-05-11 22:27:26
Message-ID: A3C8EA84-A709-4F5E-A104-35B04F28C67C () apple ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I guess it depends on value of this (and feasibility of IDE highlighting based on a \
generated source file) vs value of having a common approach for compile-time and \
runtime flags. Runtime flags and their default values likely can't be effectively \
expressed in headers.
Separate file also lets us do things like make build systems exclude files based on \
feature flag values, though of course, an alternative is to surround whole files with \
#include guards and always build everything.
> On May 11, 2020, at 9:34 AM, Alexey Proskuryakov <ap@webkit.org> wrote:
>
>
> I see substantial appeal in having a separate data file, however I'm not sure if it \
> can inform IDE parsing and syntax highlighting for code enabled/disabled at compile \
> time. Header files seem like they would get that right more often.
> - Alexey
>
>
> > 10 мая 2020 г., в 10:07 PM, Maciej Stachowiak <mjs@apple.com \
> > <mailto:mjs@apple.com>> написал(а):
> >
> > 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 <darin@apple.com \
> > > <mailto:darin@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 <mailto:webkit-dev@lists.webkit.org>
> > > https://lists.webkit.org/mailman/listinfo/webkit-dev
> >
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
[Attachment #5 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class=""><div class=""><br class=""></div>I guess it \
depends on value of this (and feasibility of IDE highlighting based on a generated \
source file) vs value of having a common approach for compile-time and runtime flags. \
Runtime flags and their default values likely can't be effectively expressed in \
headers.<div class=""><br class=""></div><div class="">Separate file also lets us do \
things like make build systems exclude files based on feature flag values, though of \
course, an alternative is to surround whole files with #include guards and always \
build everything.</div><div class=""><div class=""><div><br class=""><blockquote \
type="cite" class=""><div class="">On May 11, 2020, at 9:34 AM, Alexey Proskuryakov \
<<a href="mailto:ap@webkit.org" class="">ap@webkit.org</a>> wrote:</div><br \
class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" \
content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; \
-webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br \
class=""></div><div class="">I see substantial appeal in having a separate data file, \
however I'm not sure if it can inform IDE parsing and syntax highlighting for code \
enabled/disabled at compile time. Header files seem like they would get that right \
more often.</div><br class=""><div class=""><div class=""> <div \
style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: \
none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; \
word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" \
class=""><div class="">- Alexey</div><div class=""><br class=""></div></div><br \
class="Apple-interchange-newline">
</div>
<blockquote type="cite" class=""><div class="">10 мая 2020 г., в 10:07 PM, \
Maciej Stachowiak <<a href="mailto:mjs@apple.com" class="">mjs@apple.com</a>> \
написал(а):</div><br class="Apple-interchange-newline"><div class=""><div \
class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">- \
Maciej<br class=""><br class=""><blockquote type="cite" class="">On May 10, \
2020, at 5:13 PM, Darin Adler <<a href="mailto:darin@apple.com" \
class="">darin@apple.com</a>> wrote:<br class=""><br class="">Hi folks.<br \
class=""><br class="">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.<br class=""><br \
class="">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.<br class=""><br \
class="">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.<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">I think \
the guideline should be like this:<br class=""><br class="">All code to compute \
configuration should be in the Platform.h files, not in makefiles, with only the \
following exceptions:<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br \
class="">Options intended to be set by the environment would carefully be wrapped in \
#ifndef.<br class=""><br class="">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.<br class=""><br \
class="">What do you all think?<br class=""><br class="">— Darin<br \
class="">_______________________________________________<br class="">webkit-dev \
mailing list<br class=""><a href="mailto:webkit-dev@lists.webkit.org" \
class="">webkit-dev@lists.webkit.org</a><br class=""><a \
href="https://lists.webkit.org/mailman/listinfo/webkit-dev" \
class="">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br \
class=""></blockquote><br class="">_______________________________________________<br \
class="">webkit-dev mailing list<br class=""><a \
href="mailto:webkit-dev@lists.webkit.org" class="">webkit-dev@lists.webkit.org</a><br \
class=""><a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" \
class="">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br \
class=""></div></div></blockquote></div><br class=""><div class=""> <div \
style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: \
none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; \
word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" \
class=""><div class=""><br \
class=""></div></div></div></div></div></blockquote></div><br \
class=""></div></div></body></html>
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic