[webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[Hajime Morita]

+1 for runtime configuration.

Keeping code runnable is nice, and hard if it's disabled on many
developers' working copies.
We don't need to use traditional flag-holder like Settings class
and can use simple global-ish variables instead,
because We don't need to configure it per-Page basis.

I personally prefer compilation ENABLE flag only for possible
"optional" features,
and most of CSS functionalities aren't that case.
(This claim might be controversial though.)

--
morrita

On Thu, Jun 9, 2011 at 1:29 PM, Darin Fisher <darin at chromium.org> wrote:
> OK, but it is very nice to ship what you test (i.e., avoid the need to
> create a separate build of WebCore for testing).  Continuous integration is
> also nice (i.e., no branches).
> Marrying those constraints leads to runtime enabling features.  This is
> precisely the recipe Chromium uses to great avail for features exposed
> through JS.  Why wouldn't we want the same for CSS features?
> -Darin
>
> On Wed, Jun 8, 2011 at 5:48 PM, Adam Barth <abarth at webkit.org> wrote:
>>
>> 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
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>



-- 
morrita