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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
