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
