On Feb 11, 2014, at 10:25 AM, Benjamin Poulain <benja...@webkit.org> wrote:
> On 2/11/14, 9:26 AM, Maciej Stachowiak wrote: >> On Feb 10, 2014, at 1:38 PM, Benjamin Poulain <benja...@webkit.org> >> wrote: >>> >>> Can't we add a compile time flag instead? The chromium patch you >>> linked is inelegant and it touches some hot paths. >>> >>> Another advantage of compile time flag is Andreas eventually notice >>> when they become useless and remove all the unnecessary cruft ;) >> >> I think on the whole, runtime flags are a better way to do things. >> They allow features to get much better testing before they are turned >> on by default, among other things by enabling regression tests to >> run. They also make it more likely that both configurations keep >> compiling, regardless of which is default. > > Why not enabling the feature entirely on trunk? (and disable it when > shipping product by disabling the compile time flag?). > I think feature doing that tends to become stable a lot quicker. Occasionally a feature is so experimental you don't even want it in nightly builds - it would cause too much instability. But it's true, a lot of the time a feature is ready for testing in nightlies or developer builds, but should not be shipped just yet. I think a runtime flag is actually a good way to do that. The code that will actually compile and ship can more easily be tested that way (by testing with both modes of the flag). > We remove experimental features frequently. The compile time flags make > it a lot easier to clean up. That does seem like a benefit, though only if no one makes a mistake about what to put inside ifdefs. Not sure how to accomplish this while also maintaining the benefits of a runtime flag. Regards, Maciej _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev