[webkit-dev] Handling of feature dependencies

[Darin Adler]

On Dec 30, 2010, at 2:37 AM, Konstantin Tokarev wrote:

> What is the right way to handle dependencies between features set in time of configuration?
> 
> For example, I'd like to shrink some functionality ("feature B") in embedded browser, and therefore add option --[no]-B flag to build-webkit, but it will break existing "feature A" if it is disabled
> 
> I can see several ways how to solve it:
> * Automatically disable A in build-webkit if B is disabled
> * Replace checks for ENABLE(A) in sources with ENABLE(A) && ENABLE(B)
> * Let build fail if somebody disables B but enables A
> 
> What is the most correct way to handle this? 

Here are my thoughts on this subject matter:

    1) It's bad for the WebKit project to have too many feature flags. All those ifdefs make the code both harder to read and harder to test. I think we already have too many and would like to reduce the number.

    2) It’s bad for the web platform for WebKit to have feature flags. We want WebKit to have the same feature set everywhere, with only the few necessary exceptions for features that are either experimental and under development, or utterly inappropriate in some configurations.

    3) For the feature flags we do have, we would like them to automatically work properly in any configuration. You should not have to be an expert to set them properly.

Given those goals, I first would like to avoid adding a new feature flag. And second, in the abstract I think a failing build is the best way to handle contradictory settings. But if the settings are not contradictory we should change the code so that it will work properly.

    -- Darin