Oh, okay. Why do we have override_features.gypi then? 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.
-Darin On Wed, Jun 8, 2011 at 4:29 PM, James Robinson <[email protected]> wrote: > On Wed, Jun 8, 2011 at 4:20 PM, Darin Fisher <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>> >> > wrote: >>> >> >> >>> >> >> Is it possible for this feature to be enabled at runtime? >>> >> >> >>> >> >> On Jun 8, 2011 11:38 AM, "Adam Barth" <[email protected]> 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 <[email protected]> >>> >> >> > 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 <[email protected]> >>> >> >> >> 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 <[email protected] >>> > >>> >> >> >>> 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 >>> >> >> >>> > [email protected] >>> >> >> >>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> >> >>> > >>> >> >> >>> > >>> >> >> >>> _______________________________________________ >>> >> >> >>> webkit-dev mailing list >>> >> >> >>> [email protected] >>> >> >> >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> >> >> >>> >> >> >> >>> >> >> > _______________________________________________ >>> >> >> > webkit-dev mailing list >>> >> >> > [email protected] >>> >> >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> > >>> >> > >>> >> _______________________________________________ >>> >> webkit-dev mailing list >>> >> [email protected] >>> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> > >>> > >>> _______________________________________________ >>> webkit-dev mailing list >>> [email protected] >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> >> >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
