[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] Platform.h vs. makefiles
From: Alexey Proskuryakov <ap () webkit ! org>
Date: 2020-05-11 16:34:48
Message-ID: 5FE6EF2C-961C-4CE7-BCD7-CA2B29E46187 () webkit ! org
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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> \
> написал(а):
>
> 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> 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
[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><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><div class=""> <div style="color: rgb(0, 0, 0); \
letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; \
text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; \
-webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; \
-webkit-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="">https://lists.webkit.org/mailman/listinfo/webkit-dev<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="">https://lists.webkit.org/mailman/listinfo/webkit-dev<br \
class=""></div></div></blockquote></div><br class=""><div class=""> <div \
style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; \
text-indent: 0px; text-transform: none; white-space: normal; widows: auto; \
word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; \
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div \
class=""><br class=""></div></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