[webkit-dev] Adding ENABLE_FLEXBOX to WebCore

Dirk Pranke dpranke at chromium.org
Wed Jun 8 17:40:06 PDT 2011


No, but I hadn't even thought of that ;)

Mostly I was thinking of the pain of developers having to keep track
of which configuration was which, testing in both configurations, etc.

-- Dirk

On Wed, Jun 8, 2011 at 5:24 PM, Darin Fisher <darin at 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" <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
>


More information about the webkit-dev mailing list