[webkit-dev] FeatureDefines.h and .xcconfig
laszlo.gombos at webkit.org
Thu Aug 7 04:57:58 PDT 2014
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
> 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
> 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
On Wed, Aug 6, 2014 at 5:28 PM, Alex Christensen <achristensen at apple.com>
> 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 :)
> 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
> > 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 at lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev