[webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Adam Barth]

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" <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110608/605f0ccc/attachment.html>