[gentoo-dev] [PATCH] waf-utils.eclass: WAF_VERBOSE always effectively on

[gentoo-dev] [PATCH] waf-utils.eclass: WAF_VERBOSE always effectively on

[Joke Junkie]

Fix broken behavior not allowing to change the default verbosity.
This should be of importance to everybody building on SMP systems, since
giving the --verbose option to waf breaks a multi-job build (by making
it one-job), at least for me. This is probably a waf issue, but the
inability to change WAF_VERBOSE is clearly a bug in the eclass.
The test affected by change is always true because WAF_VERBOSE is always
set to "ON" or other non-null value. The change fixes that.
---
 eclass/waf-utils.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/waf-utils.eclass b/eclass/waf-utils.eclass
index 7acc97b10314..8b011c04b400 100644
--- a/eclass/waf-utils.eclass
+++ b/eclass/waf-utils.eclass
@@ -98,7 +98,7 @@ waf-utils_src_configure() {
 waf-utils_src_compile() {
 	debug-print-function ${FUNCNAME} "$@"
 	local _mywafconfig
-	[[ "${WAF_VERBOSE}" ]] && _mywafconfig="--verbose"
+	[[ "${WAF_VERBOSE}" = "ON" ]] && _mywafconfig="--verbose"

 	local jobs="--jobs=$(makeopts_jobs)"
 	echo "\"${WAF_BINARY}\" build ${_mywafconfig} ${jobs}"

Re: [gentoo-dev] [PATCH] waf-utils.eclass: WAF_VERBOSE always effectively on

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 1736 bytes --]

On 14/08/18 08:03, Joke Junkie wrote:
> Fix broken behavior not allowing to change the default verbosity.
> This should be of importance to everybody building on SMP systems, since
> giving the --verbose option to waf breaks a multi-job build (by making
> it one-job), at least for me. This is probably a waf issue, but the
> inability to change WAF_VERBOSE is clearly a bug in the eclass.
> The test affected by change is always true because WAF_VERBOSE is always
> set to "ON" or other non-null value. The change fixes that.
> ---
>  eclass/waf-utils.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/waf-utils.eclass b/eclass/waf-utils.eclass
> index 7acc97b10314..8b011c04b400 100644
> --- a/eclass/waf-utils.eclass
> +++ b/eclass/waf-utils.eclass
> @@ -98,7 +98,7 @@ waf-utils_src_configure() {
>  waf-utils_src_compile() {
>  	debug-print-function ${FUNCNAME} "$@"
>  	local _mywafconfig
> -	[[ "${WAF_VERBOSE}" ]] && _mywafconfig="--verbose"
> +	[[ "${WAF_VERBOSE}" = "ON" ]] && _mywafconfig="--verbose"
>
>  	local jobs="--jobs=$(makeopts_jobs)"
>  	echo "\"${WAF_BINARY}\" build ${_mywafconfig} ${jobs}"
>
There is always a trade-off here as to what a flag *means* .. does
simply specifying it mean that its 'set' or do you need one of the
following (set) to actually define it - [on,yes,y,ON,YES,Y,1].
Parsing such a set is slightly more tedious than simply accepting it's
existence, bearing in mind you need similar logic for the inverse
(OFF,off,NO,no,N,n,0].
I think the portage code-base is the one area I've seen this kinda of
option-handling (and overrides) done pretty well (potentially not
'perfect', i just said 'pretty well').

</bikeshed>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]