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