Hi, I think all ports have the very same problem, not just the OS X and iOS port. Each port need to make a decision if the build system is in control of the complete ENABLE_FEATURE_NAME set of flags or it delegates some of the defaults to FeatureDefines.h. I think it would be desired that all ports would take the same decision (even if they do not use the same build system).
> 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. Can you elaborate on why this is not true or perhaps suggest better wording ? Setting any ENABLE_FEATURE_NAME macro to an empty string in xcconfig is explicitly disabling a feature in the build system (see also the comment in e.g. WebCore/Configurations/FeatureDefines.xcconfig) > 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). The idea was that perhaps we could express the release-specific logic still in the .h file (__MAC_OS_X_VERSION_MIN_REQUIRED >= 1090), just like we do in Platform.h, but I do not know how/when XCode evaluates xcconfig rules and if running the pre-compiler from xcconfig would actually work. FeatureDefines.h was born when WebKit had many more build systems. I think it is a good time to re-evaluate if it is still useful. If build systems would control the complete ENABLE_FEATURE_NAME set and FeatureDefines.h has less use. Laszlo On Wed, Aug 6, 2014 at 5:28 PM, Alex Christensen <achristen...@apple.com> wrote: > I’ve run into similar issues. I’m working on building the Apple ports > with CMake. I would be in favor of switching everything to the xcconfig > files, but please don’t forget to edit Source/cmake/OptionsMac.cmake. Now > we have 5 files to edit, but hopefully I’ll get that down to 1 when I’m > done :) > > Alex > > 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! > > > > Dean > > > > (*) I think Apple's Windows port should probably continue with > FeatureDefines.h because it doesn't use Xcode. > > _______________________________________________ > > 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