[webkit-dev] Adding ENABLE_FLEXBOX to WebCore

[James Robinson]

On Wed, Jun 8, 2011 at 4:20 PM, Darin Fisher <darin at chromium.org> wrote:

> It seems like it doesn't scale very well to have to stand-up new buildbots
> for each
> new feature.  At least in the Chromium port, it is possible for the
> Chromium repo
> to override ENABLE_ flags so that only DRT gets built with a prototype
> feature,
> making it easy to test a prototype feature using existing buildbots.
>
>
If you mean by using feature_overrides.gypi to overwrite features.gypi, that
mechanism doesn't actually work and people have attempted to remove it.  The
bots that we actually pay attention to all use feature_overrides.gypi.  I
would not encourage that pattern.

- James

-Darin
>
>
> On Wed, Jun 8, 2011 at 3:43 PM, Adam Barth <abarth at webkit.org> wrote:
>
>> If you're super worried about folks shipping the feature before it's
>> ready, then that approach can make sense.  I'm not sure how well it
>> scales, but we can worry about that problem when we have N such
>> configurations.
>>
>> Adam
>>
>>
>> On Wed, Jun 8, 2011 at 3:19 PM, Tony Chang <tony at chromium.org> wrote:
>> > I don't understand how changing the name prevents the feature from being
>> > shipped half-done.  If we're going to ship a half-done feature, we may
>> as
>> > well use the vendor prefixed name so sites don't depend on the goofy
>> name.
>> >
>> > However, I'm willing to run a buildbot for this and that seems better
>> than
>> > shipping a half-done feature.  I don't expect it to be a core builder
>> and
>> > Ojan and I will be the ones keeping it green.  Isn't this what we're
>> doing
>> > for other features like CSS Regions and Exclusions?
>> >
>> > On Wed, Jun 8, 2011 at 12:02 PM, Adam Barth <abarth at webkit.org> wrote:
>> >>
>> >> It seems like the simplest thing is to have an ENABLE macro that's
>> >> turned on and to use the normal bots.  If you're really worried about
>> >> folks shipping the feature half-done by accident, you can use a goofy
>> >> name like -webkit-goofybox (or whatever) and rename it to the final
>> >> name when you're ready.
>> >>
>> >> Adam
>> >>
>> >>
>> >> On Wed, Jun 8, 2011 at 11:50 AM, Ojan Vafai <ojan at chromium.org> wrote:
>> >> > Kind of. We could make the functionality only work at runtime, but
>> >> > adding
>> >> > the properties to the CSS parser would be difficult to make runtime
>> >> > configurable. So, the CSS properties would parse correctly but do
>> >> > nothing.
>> >> > That's especially problematic for properties like "display" that
>> would
>> >> > then
>> >> > get an invalid value.
>> >> > My current plan was still to test this incrementally. We'd include
>> tests
>> >> > as
>> >> > we went, but skip the flexbox subdirectory. We would just run the
>> tests
>> >> > locally during development. This has the downside that other changes
>> >> > might
>> >> > break the flexbox tests, but thats a pain I'm willing to live with.
>> >> > I'm fine doing this differently if people have strong opinions.
>> >> > Ojan
>> >> >
>> >> > On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher <darin at chromium.org>
>> >> > wrote:
>> >> >>
>> >> >> Is it possible for this feature to be enabled at runtime?
>> >> >>
>> >> >> On Jun 8, 2011 11:38 AM, "Adam Barth" <abarth at webkit.org> wrote:
>> >> >> > New features should be tested incrementally as they are developed.
>> >> >> > That means running them on build.webkit.org. The decision to ship
>> a
>> >> >> > feature is separate.
>> >> >> >
>> >> >> > Adam
>> >> >> >
>> >> >> >
>> >> >> > On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai <ojan at chromium.org>
>> >> >> > wrote:
>> >> >> >> I don't think we want to ship this until we have a reasonably
>> >> >> >> feature
>> >> >> >> complete implementation of the spec and that we're convinced the
>> >> >> >> spec
>> >> >> >> is
>> >> >> >> stable. I expect that in implementing this we'll find areas of
>> the
>> >> >> >> spec
>> >> >> >> that
>> >> >> >> need reworking, but at this point it's mainly blocked on
>> >> >> >> implementation
>> >> >> >> experience.
>> >> >> >> I'm not sure it's worth setting a bot up just for this, although
>> I'm
>> >> >> >> not
>> >> >> >> opposed to it. I expect we should have this shippable within a
>> >> >> >> couple
>> >> >> >> months.
>> >> >> >>
>> >> >> >> Ojan
>> >> >> >> On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth <abarth at webkit.org>
>> >> >> >> wrote:
>> >> >> >>>
>> >> >> >>> Can't we just define ENABLE_FLEXBOX on one or more of the
>> commonly
>> >> >> >>> used ports and use the regular bots?
>> >> >> >>>
>> >> >> >>> Adam
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang <tony at chromium.org>
>> >> >> >>> wrote:
>> >> >> >>> > Hi webkit-dev,
>> >> >> >>> > I wanted to let you know that Ojan and I plan to add flexbox
>> >> >> >>> > layout
>> >> >> >>> > support
>> >> >> >>> > to WebCore.  WebCore already supports an older flexbox
>> >> >> >>> > implementation
>> >> >> >>> > (display: box), but the new spec is designed to be easier for
>> >> >> >>> > developers
>> >> >> >>> > to
>> >> >> >>> > understand and more powerful.  The old flexbox will still
>> remain
>> >> >> >>> > in
>> >> >> >>> > WebCore
>> >> >> >>> > since none of the CSS properties overlap with the new flexbox
>> >> >> >>> > spec.
>> >> >> >>> >  The
>> >> >> >>> > spec can be found
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > at: http://www.w3.org/TR/css3-flexbox/ (
>> http://dev.w3.org/csswg/css3-flexbox/)
>> >> >> >>> > This support will be behind the ENABLE_FLEXBOX feature define
>> >> >> >>> > (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is
>> a
>> >> >> >>> > meta
>> >> >> >>> > bug
>> >> >> >>> > tracking the feature's development
>> >> >> >>> > (https://bugs.webkit.org/show_bug.cgi?id=62048).  I expect
>> this
>> >> >> >>> > feature
>> >> >> >>> > to
>> >> >> >>> > eventually be enabled by all ports.
>> >> >> >>> > I am ready to setup a buildbot for tracking the compile and
>> >> >> >>> > flexbox
>> >> >> >>> > related
>> >> >> >>> > layout tests.  Should I go ahead and get this added to
>> >> >> >>> > build.webkit.org's
>> >> >> >>> > waterfall?
>> >> >> >>> > Thanks,
>> >> >> >>> > Tony
>> >> >> >>> >
>> >> >> >>> > _______________________________________________
>> >> >> >>> > webkit-dev mailing list
>> >> >> >>> > webkit-dev at lists.webkit.org
>> >> >> >>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> _______________________________________________
>> >> >> >>> webkit-dev mailing list
>> >> >> >>> webkit-dev at lists.webkit.org
>> >> >> >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >> >> >>
>> >> >> >>
>> >> >> > _______________________________________________
>> >> >> > webkit-dev mailing list
>> >> >> > webkit-dev at lists.webkit.org
>> >> >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >> >
>> >> >
>> >> _______________________________________________
>> >> webkit-dev mailing list
>> >> webkit-dev at lists.webkit.org
>> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >
>> >
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110608/07f42244/attachment.html>