Chiebot-Mirror/meson - meson - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
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
Dylan Baker	3589815eb9	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
Paolo Bonzini	a87e32d181	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
Paolo Bonzini	2f2d99e1d8	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
Paolo Bonzini	08a8043f19	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
Jussi Pakkanen	e75e3976fa	Condense test directory names.	4 years ago