meson

The Meson Build System http://mesonbuild.com/

Dylan Baker b2473b61cc interpreter: add FeatureOption.enable_if and .disable_if 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.	2 years ago
..
meson.build	interpreter: add FeatureOption.enable_if and .disable_if	2 years ago
meson_options.txt	Condense test directory names.	4 years ago

Dylan Baker b2473b61cc interpreter: add FeatureOption.enable_if and .disable_if

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.

2 years ago

meson.build

interpreter: add FeatureOption.enable_if and .disable_if

2 years ago

meson_options.txt

Condense test directory names.

4 years ago