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
