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
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 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
