+1 for runtime configuration. Keeping code runnable is nice, and hard if it's disabled on many developers' working copies. We don't need to use traditional flag-holder like Settings class and can use simple global-ish variables instead, because We don't need to configure it per-Page basis.
I personally prefer compilation ENABLE flag only for possible "optional" features, and most of CSS functionalities aren't that case. (This claim might be controversial though.) -- morrita On Thu, Jun 9, 2011 at 1:29 PM, Darin Fisher <da...@chromium.org> wrote: > OK, but it is very nice to ship what you test (i.e., avoid the need to > create a separate build of WebCore for testing). Continuous integration is > also nice (i.e., no branches). > Marrying those constraints leads to runtime enabling features. This is > precisely the recipe Chromium uses to great avail for features exposed > through JS. Why wouldn't we want the same for CSS features? > -Darin > > On Wed, Jun 8, 2011 at 5:48 PM, Adam Barth <aba...@webkit.org> wrote: >> >> The difference between runtime and compile time enabling seems like a red >> herring. The issue is more which configurations to test where and to ship >> where, not how to do the configuring. >> >> Adam >> >> On Jun 8, 2011 5:25 PM, "Darin Fisher" <da...@chromium.org> wrote: >> > Are you referring to the additional cost of maintaining different test >> > expectations between the two configs? Agreed, that would suck. >> > >> > So, how painful would it be to add runtime enablement support for new >> > CSS >> > features? >> > On Jun 8, 2011 5:16 PM, "Dirk Pranke" <dpra...@chromium.org> wrote: >> >> On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher <da...@chromium.org> >> >> wrote: >> >>> >> >>> >> >>> On Wed, Jun 8, 2011 at 4:59 PM, James Robinson <jam...@google.com> >> >>> wrote: >> >>>> >> >>>> On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher <da...@chromium.org> >> >>>> wrote: >> >>>>> >> >>>>> Oh, okay. Why do we have override_features.gypi then? >> >>>> >> >>>> We don't, Adam tried to remove it earlier this week and was foiled by >> > some >> >>>> weird complex failure. We should get rid of it ASAP. >> >>> >> >>> OK ... I guess things have changed. >> >>> >> >>>>> >> >>>>> Regardless, it seems like we could create a mechanism so that the >> > result >> >>>>> of build-webkit >> >>>>> uses different ENABLE_ options than a stock Chromium build. There's >> >>>>> a >> >>>>> trivial way to switch >> >>>>> b/w the two in the GYP files. >> >>>> >> >>>> There's danger in testing a different set of ENABLE_s than we ship >> > unless >> >>>> we are really confident in understanding how the ENABLE_'d code >> > interacts >> >>>> with the rest of the codebase. >> >>> >> >>> >> >>> I'm not sure that is a big deal. The Chromium build bots at >> >>> build.chromium.org run DRT built from a Chromium checkout. The >> >>> build.webkit.org bots are intended to provide compile and DRT feedback >> > for >> >>> the Chromium port that is visible to the rest of the WebKit community. >> > If >> >>> the configs between build.webkit.org and build.chromium.org differ, >> >>> maybe >> >>> that is not so bad? >> >> >> >> Boy, that seems like a recipe for pain from my point of view. I'd be >> >> against this unless there was a *big* win for some reason. >> >> >> >> -- Dirk > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -- morrita _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
