> On Aug 7, 2014, at 09:36, Maciej Stachowiak <m...@apple.com> wrote: > >> >> On Aug 6, 2014, at 2:22 PM, Dean Jackson <d...@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.
At a quick glance: Source/WebCore/DerivedSources.make contains numerous tests of ENABLE flags which I’d guess could be eliminated as you suggest. Source/WebCore/bindings/scripts/CodeGeneratorObjC.pm appears to have at least one test of ENABLE flags, which is an interesting case since we can’t generate these #ifs in to the Objective-C DOM API headers. The various CMake files used by other ports also contain a large number of tests of ENABLE flags to add search paths or link against different libraries when particular features are enabled. I’m not sure this can be avoided. The JavaScriptCore Xcode project has script phases that do different work depending on whether or not ENABLE_FTL_JIT is set. It’s not sure this can be avoided. - Mark
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
