Chiebot-Mirror
/
meson
mirror of https://github.com/mesonbuild/meson.git
8
0
Fork 0
Code Issues Projects Releases Wiki Activity
The Meson Build System http://mesonbuild.com/
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
13973 Commits
76 Branches
171 Tags
76 MiB
Tag: Branch: Tree: 8758e1353e
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '8758e1353e'
${ noResults }
meson/test cases/common/192 feature option/meson.build

79 lines
4.2 KiB
Raw Normal View History Unescape

compilers/d: Add b_ndebug support D lang compilers have an option -release (or similar) which turns off asserts, contracts, and other runtime type checking. This patch wires that up to the b_ndebug flag. Fixes #7082
5 years ago
project('feature user option', 'c')
feature_opts = get_option('auto_features')
required_opt = get_option('required')
optional_opt = get_option('optional')
disabled_opt = get_option('disabled')
assert(not feature_opts.enabled(), 'Should be auto option')
assert(not feature_opts.disabled(), 'Should be auto option')
assert(feature_opts.auto(), 'Should be auto option')
interpreter: add feature.allowed() This method simplifies the conversion of Feature objects to booleans. Often, one has to use the "not" operator in order to treat "auto" and "enabled" the same way. "allowed()" also works well in conjunction with the require method that is introduced in the next patch. For example, if get_option('foo').require(host_machine.system() == 'windows').allowed() then src += ['foo.c'] config.set10('HAVE_FOO', 1) endif can be used instead of if host_machine.system() != 'windows' if get_option('foo').enabled() error('...') endif endif if not get_option('foo').disabled() then src += ['foo.c'] config.set10('HAVE_FOO', 1) endif Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
4 years ago
assert(feature_opts.allowed(), 'Should be auto option')
compilers/d: Add b_ndebug support D lang compilers have an option -release (or similar) which turns off asserts, contracts, and other runtime type checking. This patch wires that up to the b_ndebug flag. Fixes #7082
5 years ago
assert(required_opt.enabled(), 'Should be enabled option')
assert(not required_opt.disabled(), 'Should be enabled option')
assert(not required_opt.auto(), 'Should be enabled option')
interpreter: add feature.allowed() This method simplifies the conversion of Feature objects to booleans. Often, one has to use the "not" operator in order to treat "auto" and "enabled" the same way. "allowed()" also works well in conjunction with the require method that is introduced in the next patch. For example, if get_option('foo').require(host_machine.system() == 'windows').allowed() then src += ['foo.c'] config.set10('HAVE_FOO', 1) endif can be used instead of if host_machine.system() != 'windows' if get_option('foo').enabled() error('...') endif endif if not get_option('foo').disabled() then src += ['foo.c'] config.set10('HAVE_FOO', 1) endif Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
4 years ago
assert(required_opt.allowed(), 'Should be enabled option')
interpreter: add feature.require() Add a method to perform a logical AND on a feature object. The method also takes care of raising an error if 'enabled' is ANDed with false. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
4 years ago
assert(required_opt.require(true, error_message: 'xyz').enabled(), 'Should be enabled option')
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
assert(required_opt.enable_if(true, error_message: 'xyz').enabled(), 'Should be enabled option')
assert(required_opt.enable_if(false, error_message: 'xyz').enabled(), 'Should be enabled option')
assert(required_opt.disable_if(false, error_message: 'xyz').enabled(), 'Should be enabled option')
interpreter: add feature.disable_auto_if() Add a method to downgrade an option to disabled if it is not used. This is useful to avoid unnecessary search for dependencies; for example dep = dependency('dep', required: get_option('feature').disable_auto_if(not foo)) can be used instead of the more verbose and complex if get_option('feature').auto() and not foo then dep = dependency('', required: false) else dep = dependency('dep', required: get_option('feature')) endif or to avoid unnecessary dependency searches: dep1 = dependency('dep1', required: get_option('foo')) # dep2 is only used together with dep1 dep2 = dependency('dep2', required: get_option('foo').disable_auto_if(not dep1.found())) ``` Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
4 years ago
assert(required_opt.disable_auto_if(true).enabled(), 'Should be enabled option')
assert(required_opt.disable_auto_if(false).enabled(), 'Should be enabled option')
interpreter: add a feature.enable_auto_if 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) ```
2 years ago
assert(required_opt.enable_auto_if(true).enabled(), 'Should be enabled option')
assert(required_opt.enable_auto_if(false).enabled(), 'Should be enabled option')
compilers/d: Add b_ndebug support D lang compilers have an option -release (or similar) which turns off asserts, contracts, and other runtime type checking. This patch wires that up to the b_ndebug flag. Fixes #7082
5 years ago
assert(not optional_opt.enabled(), 'Should be auto option')
assert(not optional_opt.disabled(), 'Should be auto option')
assert(optional_opt.auto(), 'Should be auto option')
interpreter: add feature.allowed() This method simplifies the conversion of Feature objects to booleans. Often, one has to use the "not" operator in order to treat "auto" and "enabled" the same way. "allowed()" also works well in conjunction with the require method that is introduced in the next patch. For example, if get_option('foo').require(host_machine.system() == 'windows').allowed() then src += ['foo.c'] config.set10('HAVE_FOO', 1) endif can be used instead of if host_machine.system() != 'windows' if get_option('foo').enabled() error('...') endif endif if not get_option('foo').disabled() then src += ['foo.c'] config.set10('HAVE_FOO', 1) endif Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
4 years ago
assert(optional_opt.allowed(), 'Should be auto option')
interpreter: add feature.require() Add a method to perform a logical AND on a feature object. The method also takes care of raising an error if 'enabled' is ANDed with false. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
4 years ago
assert(optional_opt.require(true).auto(), 'Should be auto option')
assert(optional_opt.require(false, error_message: 'xyz').disabled(), 'Should be disabled auto option')
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
assert(optional_opt.enable_if(true).enabled(), 'Should be enabled option')
assert(optional_opt.enable_if(false).auto(), 'Should be auto option')
assert(optional_opt.disable_if(true).disabled(), 'Should be disabled auto option')
assert(optional_opt.disable_if(false).auto(), 'Should be auto option')
interpreter: add feature.disable_auto_if() Add a method to downgrade an option to disabled if it is not used. This is useful to avoid unnecessary search for dependencies; for example dep = dependency('dep', required: get_option('feature').disable_auto_if(not foo)) can be used instead of the more verbose and complex if get_option('feature').auto() and not foo then dep = dependency('', required: false) else dep = dependency('dep', required: get_option('feature')) endif or to avoid unnecessary dependency searches: dep1 = dependency('dep1', required: get_option('foo')) # dep2 is only used together with dep1 dep2 = dependency('dep2', required: get_option('foo').disable_auto_if(not dep1.found())) ``` Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
4 years ago
assert(optional_opt.disable_auto_if(true).disabled(), 'Should be disabled auto option')
assert(optional_opt.disable_auto_if(false).auto(), 'Should be auto option')
interpreter: add a feature.enable_auto_if 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) ```
2 years ago
assert(optional_opt.enable_auto_if(true).enabled(), 'Should be disabled auto option')
assert(optional_opt.enable_auto_if(false).auto(), 'Should be auto option')
compilers/d: Add b_ndebug support D lang compilers have an option -release (or similar) which turns off asserts, contracts, and other runtime type checking. This patch wires that up to the b_ndebug flag. Fixes #7082
5 years ago
assert(not disabled_opt.enabled(), 'Should be disabled option')
assert(disabled_opt.disabled(), 'Should be disabled option')
assert(not disabled_opt.auto(), 'Should be disabled option')
interpreter: add feature.allowed() This method simplifies the conversion of Feature objects to booleans. Often, one has to use the "not" operator in order to treat "auto" and "enabled" the same way. "allowed()" also works well in conjunction with the require method that is introduced in the next patch. For example, if get_option('foo').require(host_machine.system() == 'windows').allowed() then src += ['foo.c'] config.set10('HAVE_FOO', 1) endif can be used instead of if host_machine.system() != 'windows' if get_option('foo').enabled() error('...') endif endif if not get_option('foo').disabled() then src += ['foo.c'] config.set10('HAVE_FOO', 1) endif Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
4 years ago
assert(not disabled_opt.allowed(), 'Should be disabled option')
interpreter: add feature.require() Add a method to perform a logical AND on a feature object. The method also takes care of raising an error if 'enabled' is ANDed with false. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
4 years ago
assert(disabled_opt.require(true).disabled(), 'Should be disabled option')
assert(disabled_opt.require(false, error_message: 'xyz').disabled(), 'Should be disabled option')
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
assert(disabled_opt.enable_if(false).disabled(), 'Should be disabled option')
assert(disabled_opt.disable_if(true).disabled(), 'Should be disabled option')
assert(disabled_opt.disable_if(false).disabled(), 'Should be disabled option')
interpreter: add feature.disable_auto_if() Add a method to downgrade an option to disabled if it is not used. This is useful to avoid unnecessary search for dependencies; for example dep = dependency('dep', required: get_option('feature').disable_auto_if(not foo)) can be used instead of the more verbose and complex if get_option('feature').auto() and not foo then dep = dependency('', required: false) else dep = dependency('dep', required: get_option('feature')) endif or to avoid unnecessary dependency searches: dep1 = dependency('dep1', required: get_option('foo')) # dep2 is only used together with dep1 dep2 = dependency('dep2', required: get_option('foo').disable_auto_if(not dep1.found())) ``` Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
4 years ago
assert(disabled_opt.disable_auto_if(true).disabled(), 'Should be disabled option')
assert(disabled_opt.disable_auto_if(false).disabled(), 'Should be disabled option')
interpreter: add a feature.enable_auto_if 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) ```
2 years ago
assert(disabled_opt.enable_auto_if(true).disabled(), 'Should be disabled option')
assert(disabled_opt.enable_auto_if(false).disabled(), 'Should be disabled option')
compilers/d: Add b_ndebug support D lang compilers have an option -release (or similar) which turns off asserts, contracts, and other runtime type checking. This patch wires that up to the b_ndebug flag. Fixes #7082
5 years ago
dep = dependency('threads', required : required_opt)
assert(dep.found(), 'Should find required "threads" dep')
dep = dependency('threads', required : optional_opt)
assert(dep.found(), 'Should find optional "threads" dep')
dep = dependency('threads', required : disabled_opt)
assert(not dep.found(), 'Should not find disabled "threads" dep')
dep = dependency('notfounddep', required : optional_opt)
assert(not dep.found(), 'Should not find optional "notfounddep" dep')
dep = dependency('notfounddep', required : disabled_opt)
assert(not dep.found(), 'Should not find disabled "notfounddep" dep')
cc = meson.get_compiler('c')
lib = cc.find_library('m', required : disabled_opt)
assert(not lib.found(), 'Should not find "m" library')
cp = find_program('cp', required : disabled_opt)
assert(not cp.found(), 'Should not find "cp" program')
found = add_languages('cpp', required : disabled_opt)
assert(not found, 'Should not find "cpp" language')