[webkit-dev] Adding ENABLE_FLEXBOX to WebCore

Darin Fisher darin at chromium.org
Wed Jun 8 17:24:48 PDT 2011


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" <dpranke at chromium.org> wrote:
> On Wed, Jun 8, 2011 at 5:13 PM, Darin Fisher <darin at chromium.org> wrote:
>>
>>
>> On Wed, Jun 8, 2011 at 4:59 PM, James Robinson <jamesr at google.com> wrote:
>>>
>>> On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher <darin at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110608/fcc68713/attachment.html>


More information about the webkit-dev mailing list