[webkit-dev] FeatureDefines.h and .xcconfig

[Maciej Stachowiak]

> On Aug 6, 2014, at 2:22 PM, Dean Jackson <dino at apple.com> wrote:
> 
> Hi floks,
> 
> Things are a bit confusing in the OS X and iOS build configurations because we have both a FeatureDefines.h and a set of .xcconfig files, often defining the same thing, and sometimes inconsistently (or at least I've made the mistake of turning a feature off in one place when the other place turned it back on).
> 
> Obviously it would be good to have only one location for feature enabling.
> 
> While FeatureDefines.h says "Use this file to list _all_ ENABLE() macros" it also says "The feature defaults in this file are only taken into account if the (port specific) build system has not enabled or disabled a particular feature", which is not true.
> 
> My proposal is to stop using FeatureDefines.h for the Apple ports (*) and move completely to .xcconfig files. 
> 
> Notes:
> 
> - Some scripts launched by Xcode might use the ENABLE_WHATEVER environment variables (which FeatureDefines.h can't provide)
> 
> - The xcconfig files will probably have to be of the form ENABLE_WHATEVER=0 to disable a feature, rather than just leaving it blank.
> 
> - We'd have to change from #ifdef to #if in places.
> 
> - You'd always have to edit 4 files to toggle a feature :(
> 
> - Generating the FeatureDefines.xcconfig from FeatureDefines.h might be cool, but we have a fair amount of release-specific logic in there (e.g. only enabled on 10.9).
> 
> Is this a terrible idea? Please suggest a better one!

I’d like to propose the opposite: do all feature configuration in header files, and none in port-specific build system files. .xconfig files have a bunch of disadvantages. They are harder to find, harder to edit (since there are multiple), harder to do conditionals in. It also makes it much harder to figure out the feature flag settings for all ports, and to share common defaults.

If there are scripts depending on ENABLE flags, we should probably fix that. If the scripts generate source, they could create source files with #ifdefs in them instead of testing the flags themselves. Having scripts produce different sources based on build-time settings is more likely to lead to bad builds and broken dependencies, and should be avoided. I would like to know which scripts actually depend on ENABLE_WHATEVER.

My longstanding proposal for this is that every port has its own header to define feature flags, which can includes a default one that includes the project-recommended default settings for each feature. The build system can use include paths to choose the right one. This also makes it easier to have multiple sub-configurations per port, so for example we could have a different set of flags for nightlies and production builds. This would allow experimentation in nightlies without the need for last-minute fiddling with flags on release branches to avoid accidentally shipping things.

Regards,
Maciej