<div dir="ltr">Hi,<div><br></div><div><div>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).</div>
<div><br></div><div>> 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.</div>
<div><br></div><div>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)</div>
<div><br></div><div>> 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).</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Laszlo</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 6, 2014 at 5:28 PM, Alex Christensen <span dir="ltr"><<a href="mailto:achristensen@apple.com" target="_blank">achristensen@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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 :)<br>
<span class=""><font color="#888888"><br>
Alex<br>
</font></span><div class=""><div class="h5"><br>
On Aug 6, 2014, at 2:22 PM, Dean Jackson <<a href="mailto:dino@apple.com">dino@apple.com</a>> wrote:<br>
<br>
> Hi floks,<br>
><br>
> 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).<br>
><br>
> Obviously it would be good to have only one location for feature enabling.<br>
><br>
> 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.<br>
><br>
> My proposal is to stop using FeatureDefines.h for the Apple ports (*) and move completely to .xcconfig files.<br>
><br>
> Notes:<br>
><br>
> - Some scripts launched by Xcode might use the ENABLE_WHATEVER environment variables (which FeatureDefines.h can't provide)<br>
><br>
> - The xcconfig files will probably have to be of the form ENABLE_WHATEVER=0 to disable a feature, rather than just leaving it blank.<br>
><br>
> - We'd have to change from #ifdef to #if in places.<br>
><br>
> - You'd always have to edit 4 files to toggle a feature :(<br>
><br>
> - 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).<br>
><br>
> Is this a terrible idea? Please suggest a better one!<br>
><br>
> Dean<br>
><br>
> (*) I think Apple's Windows port should probably continue with FeatureDefines.h because it doesn't use Xcode.<br>
> _______________________________________________<br>
> webkit-dev mailing list<br>
> <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
> <a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br>
<br>
_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br>
</div></div></blockquote></div><br></div></div></div>