> 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

Reply via email to