I made https://trac.webkit.org/wiki/FeatureFlags .
I extracted all of ENABLE(FOO) in *.cpp and *.mm, and added some comments.
Feel free to edit it!
On Wed, Mar 14, 2012 at 13:03, TAMURA, Kent <[email protected]> wrote:
I'll add a Wiki page for the table of existing feature flags and their
descriptions.
On Tue, Feb 14, 2012 at 11:09, Maciej Stachowiak <[email protected]> wrote:
I think we're talking about a couple of different things now:
1) Table of what the WebKit community as a whole (instead of individual
point maintainers) thinks should be enabled in stable releases. This
would
be input to port maintainers looking to make a release.
2) Documenting what enable flags are actually on for given ports as
shipped. Probably hard to gather this info, but might be useful input for
the WebKit community.
3) Changing build systems to enable compiling "nightly" and "stable"
versions from the same tree, so both modes are documented in trunk.
Requires some coding for various build systems.
I like (2) and (3), but I don't think they replace the usefulness of (1).
I think the mention of "the feature-table page" is blending (2) and (1),
which would serve different purposes.
Regards,
Maciej
On Feb 13, 2012, at 4:21 PM, Hajime Morrita wrote:
> (Re-sending from the right address...)
>
> I'd +1 Adam's point.
>
> It would be great if we can do something like "webkit-build --gtk
> --stable", "webkit-build --chromium --canary" or "webkit-build
> --nightly" where the script read the central configuration file and
> find an appropriate configuration. In this way, there would be no
> duplication we should maintain.
>
> Even though some ports currently don't support switches through
> build-webkit, we can gradually switch over to the central list-based
> configuration settings by, for example, generating features.gypi,
> FeatureDefines.xcconfig or a set of flags for autoconf.
>
> Also the feature-table page could be generated from the list. We can
> even start from simply generating an HTML from the machine-readable
> configuration file, then integrate it to each build system.
>
> Although it might be overkill, I personally prefer this kind of "don't
> repeat youself" direction.
> --
> morrita
>
> On Tue, Feb 14, 2012 at 8:11 AM, Maciej Stachowiak <[email protected]>
wrote:
>>
>> On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote:
>>
>> On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak <[email protected]>
wrote:
>>>
>>> I think you raise a good point. Another point worth mentioning is
that
>>> sometimes a feature can be complete and useful in one port, but
half-baked
>>> in another (for example, fullscreen API was shipped in Safari and at
the
>>> same time present but non-functional in Chrome).
>>>
>>> I think in the past, port owners have made clear that they want to
own the
>>> final decisions on what features are enabled in their ports.
>>>
>>> But we as a community could do better, by having a shared
recommendation
>>> of what features we think should be enabled in shipping releases. In
some
>>> cases, this may not match the settings on trunk, as some features may
be
>>> desirable to enable for experimental builds, but not in shipping
product.
>>> For features that we recommended disabling, ideally we'd identify a
reason.
>>> And in some cases, those might be port-specific issues.
>>
>>
>> Right. Even just having a list of new features with flag(s) to
>> enable/disable and the status (e.g. list of outstanding bugs) on wiki
page
>> will be helpful.
>>
>> For example, vertical writing mode doesn't work on Windows, Chromium,
etc...
>> but port owners may not necessarily realize that the feature is
enabled by
>> default and each port needs to modify the code that draws text.
>>
>>
>> I personally think such a page would be a good idea. I'd love to hear
input
>> from more folks on whether this is a good idea and what the right
approach
>> is.
>>
>> Cheers,
>> Maciej
>>
>> _______________________________________________
>> webkit-dev mailing list
>> [email protected]
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
TAMURA Kent
Software Engineer, Google
--
TAMURA Kent
Software Engineer, Google
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
