--===============1010904341== Content-type: multipart/alternative; boundary="Apple-Mail=_3B73AC97-82FD-4F61-9C17-5942FD2E4C06" --Apple-Mail=_3B73AC97-82FD-4F61-9C17-5942FD2E4C06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=E2=80=99t 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 = wrote: >=20 >=20 > 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. >=20 > - Alexey >=20 >=20 >> 10 =D0=BC=D0=B0=D1=8F 2020 =D0=B3., =D0=B2 10:07 PM, Maciej = Stachowiak > =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0=D0=BB(=D0=B0): >>=20 >>=20 >> 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. >>=20 >> 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. >>=20 >> - Maciej >>=20 >>> On May 10, 2020, at 5:13 PM, Darin Adler > wrote: >>>=20 >>> Hi folks. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> If these truly are WebKit consumer options, then it=E2=80=99s = 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. >>>=20 >>> 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. >>>=20 >>> Thus I think the pattern on macOS, for example, of setting these in = .xcconfig files doesn=E2=80=99t 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. >>>=20 >>> I think the guideline should be like this: >>>=20 >>> All code to compute configuration should be in the Platform.h files, = not in makefiles, with only the following exceptions: >>>=20 >>> 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=E2=80=99s maintainers. Ideally we=E2=80=99d find a way = to not repeat these default settings twice. >>>=20 >>> 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. >>>=20 >>> Options intended to be set by the environment would carefully be = wrapped in #ifndef. >>>=20 >>> 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. >>>=20 >>> What do you all think? >>>=20 >>> =E2=80=94 Darin >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>=20 >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev >=20 >=20 --Apple-Mail=_3B73AC97-82FD-4F61-9C17-5942FD2E4C06 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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=E2=80=99t 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 =D0=BC=D0=B0=D1=8F= 2020 =D0=B3., =D0=B2 10:07 PM, Maciej Stachowiak <mjs@apple.com> = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):


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=E2=80=99s 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=E2=80=99t 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=E2=80=99s maintainers. Ideally we=E2=80=99d = 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?

=E2=80=94 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



= --Apple-Mail=_3B73AC97-82FD-4F61-9C17-5942FD2E4C06-- --===============1010904341== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev --===============1010904341==--