[webkit-dev] On web-exposing features disabled at runtime

[Maciej Stachowiak]

On Feb 11, 2014, at 10:25 AM, Benjamin Poulain <benjamin at webkit.org> wrote:

> On 2/11/14, 9:26 AM, Maciej Stachowiak wrote:
>> On Feb 10, 2014, at 1:38 PM, Benjamin Poulain <benjamin at 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