Great. Thanks! On Thu, Mar 15, 2012 at 5:01 AM, TAMURA, Kent <[email protected]> wrote:
> 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 >>> Software Engineer >>> Google Inc. >>> >>> >>> 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 > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
