[webkit-dev] When should we turn on new features?
tkent at chromium.org
Thu Mar 15 05:01:47 PDT 2012
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 <tkent at chromium.org> wrote:
> I'll add a Wiki page for the table of existing feature flags and their
> On Tue, Feb 14, 2012 at 11:09, Maciej Stachowiak <mjs at apple.com> 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
>> 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.
>> 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 <mjs at apple.com>
>> >> On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote:
>> >> On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak <mjs at apple.com>
>> >>> I think you raise a good point. Another point worth mentioning is
>> >>> sometimes a feature can be complete and useful in one port, but
>> >>> in another (for example, fullscreen API was shipped in Safari and at
>> >>> 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
>> >>> of what features we think should be enabled in shipping releases. In
>> >>> cases, this may not match the settings on trunk, as some features may
>> >>> desirable to enable for experimental builds, but not in shipping
>> >>> For features that we recommended disabling, ideally we'd identify a
>> >>> 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
>> >> will be helpful.
>> >> For example, vertical writing mode doesn't work on Windows, Chromium,
>> >> 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
>> >> from more folks on whether this is a good idea and what the right
>> >> is.
>> >> Cheers,
>> >> Maciej
>> >> _______________________________________________
>> >> webkit-dev mailing list
>> >> webkit-dev at lists.webkit.org
>> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
> TAMURA Kent
> Software Engineer, Google
Software Engineer, Google
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev