1057342012-12-24 21:46:05 -0800[Meta] Maintain a full list of ENABLE defines and default values in C header(s)2013-01-29 07:09:39 -0800111UnclassifiedWebKitPlatform528+ (Nightly build)UnspecifiedUnspecifiedNEWP2Normal---1081931057351laszlo.gomboswebkit-unassignedabecsidinoerictkentoldest_to_newest7970870laszlo.gombos2012-12-24 21:46:05 -0800There is a common interest to track the list of feature flags for the WebKit. At the moment the most complete list of feature flags are maintained on the WebKit Wiki (see http://trac.webkit.org/wiki/FeatureFlags ).
I propose to maintain the list of feature flags in (a) header file(s) instead of a wiki page that is disconnected from the source code. This approach has the following benefits:
- Requires one (or perhaps more than one in the future) less steps to introduce a new feature flag (see also http://trac.webkit.org/wiki/AddingFeatures ).
- The list of features and the source code is revisioned together, the two are never out of sync.
- We could use the existing contribution process and tools to make sure that the list is correctly maintained (e.g. check-webkit-style could check if a patch uses an ENABLE macro that is not listed in the feature list header file.).
- In the future this header file could be used by the port specific build system (and perhaps build-webkit as well) to get the list of features and the default values for those features.
- We should also consider layer these macros properly together with the frameworks/libraries - have one header file for WebCore and a separate one for JavaScriptCore and move them out from WTF (Platform.h).
I opened this bug as a meta bug as I expect several steps/patches to make some of these ideas happen.8019861tkent2013-01-07 21:03:10 -0800> I propose to maintain the list of feature flags in (a) header file(s) instead of a wiki page that is disconnected from the source code.
I basically agree with it.
My concern is existing explanation comments in the wiki page. Do you want to move the comments to the header file?8098012laszlo.gombos2013-01-17 14:37:33 -0800(In reply to comment #1)
> > I propose to maintain the list of feature flags in (a) header file(s) instead of a wiki page that is disconnected from the source code.
>
> I basically agree with it.
> My concern is existing explanation comments in the wiki page. Do you want to move the comments to the header file?
Yes I was planning to move the comments from the FeatureFlags wiki to the header file. The source browser on trac.webkit.org can be used to link to the file on the web.8100153tkent2013-01-17 17:54:07 -0800> - In the future this header file could be used by the port specific build system (and perhaps build-webkit as well) to get the list of features and the default values for those features.
This sounds difficult. We need the list of feature flags in non-C++ code too.
For example, binding generators, dom/make_names.pl, css/makeprop.pl, css/makevalues.pl, etc.8101204laszlo.gombos2013-01-17 19:30:09 -0800(In reply to comment #3)
> > - In the future this header file could be used by the port specific build system (and perhaps build-webkit as well) to get the list of features and the default values for those features.
>
> This sounds difficult. We need the list of feature flags in non-C++ code too.
> For example, binding generators, dom/make_names.pl, css/makeprop.pl, css/makevalues.pl, etc.
One way to export the values of the feature configurations to the build system it is to run the preprocessor on the header file with all the same build flags that the build system would otherwise use (e.g. to establish the port).
This technique is already used in WebCore/DerivedSources.make (check how the defaults for ENABLE_DASHBOARD_SUPPORT and for ENABLE_ORIENTATION_EVENTS are set).
This is just a potential and the risks needs to be discussed with the benefits.