summaryrefslogtreecommitdiff
path: root/docs/yaml/objects/feature.yaml
AgeCommit message (Collapse)Author
2024-08-05docs: fix example for feature.requireMarvin Scholz
The example incorrectly uses `then` after the if condition, which is incorrect meson syntax as meson does not support a `then` keyword.
2023-08-18docs: Provide example for feature.disable_auto_ifJan Janssen
2023-08-16Fix some random capitalization in feature.yamlTristan Partin
2023-08-11docs: Add more feature truth tablesJan Janssen
These are much easier to understand at a glance than free-form text.
2023-05-23docs: Fix some typos in feature option examplesNirbheek Chauhan
2023-02-15interpreter: add FeatureOption.enable_if and .disable_ifDylan Baker
This adds two new methods, that are conceptually related in the same way that `enable_auto_if` and `disable_auto_if` are. They are different however, in that they will always replace an `auto` value with an `enabled` or `disabled` value, or error if the feature is in the opposite state (calling `feature(disabled).enable_if(true)`, for example). This matters when the feature will be passed to dependency(required : …)`, which has different behavior when passed an enabled feature than an auto one. The `disable_if` method will be controversial, I'm sure, since it can be expressed via `feature.require()` (`feature.require(not condition) == feature.disable_if(condition)`). I have two defences of this: 1) `feature.require` is difficult to reason about, I would expect require to be equivalent to `feature.enable_if(condition)`, not to `feature.disable_if(not condition)`. 2) mixing `enable_if` and `disable_if` in the same call chain is much clearer than mixing `require` and `enable_if`: ```meson get_option('feat') \ .enable_if(foo) \ .disable_if(bar) \ .enable_if(opt) ``` vs ```meson get_option('feat') \ .enable_if(foo) \ .require(not bar) \ .enable_if(opt) ``` In the first chain it's immediately obvious what is happening, in the second, not so much, especially if you're not familiar with what `require` means.
2023-02-15interpreter: add a feature.enable_auto_ifDylan Baker
It's always been strange to me we don't have an opposite method of the `disable_auto_if` method, but I've been pressed to find a case where we _need_ one, because `disable_auto_if` can't be logically contorted to work. I finally found the case where they're not equivalent: when you don't want to convert to a boolean: ```meson f = get_option('feat').disable_auto_if(not foo) g = get_option('feat').enable_auto_if(foo) dep1 = dependency('foo', required : f) dep2 = dependency('foo', required : g) ```
2022-01-18interpreterobjects: deprecated passing a number to configuration_data.set10Dylan Baker
This is currently allowed, and is used in at least a few projects. It was not intended to work or documented, but it does and since it is in use a full deprecation period must be used. A warning has also been added for values < 0, which have surprising behavior.
2021-10-03docs: Add the YAML Reference manualDaniel Mensinger