> On May 10, 2020, at 10:07 PM, Maciej Stachowiak <m...@apple.com> wrote: > > 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.
Sounds OK. I worry a little about defining yet another language, but otherwise I do find this appealing. Perhaps some people would say that FeatureDefines.props from cmake could be that file? Not sure literally a single data file is the best way to do this across multiple platforms/ports. I think PlatformEnableCocoa.h shows us that breaking this down can be helpful. One file that has the master list of all the settings, and all the default values. Then other files that contain overlays for each port/configuration where they are different from the default. My worry is that it could become complicated, like our TestExpectations files, which were once simple. > 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. Yes, I’m not suggesting rushing to do it all at once in a mass change. But for new things especially on Apple’s Cocoa platforms, I’d like to avoid FeatureDefines.xcconfig and see new things in the PlatformEnableCocoa.h header file instead. Unless the defines need to affect the build system and not just the C++ code, I think the header file is superior. — Darin _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
