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>
signature.asc
Description: OpenPGP digital signature
