[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