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 <m...@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 <da...@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


_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to