On Fri, 27 Mar 2015 17:45:30 +0100, Pavel Raiskup wrote: > On Wednesday 11 of March 2015 02:06:40 Mirko Vogt wrote: > > I just stumbled across an issue where a project fails to compile using > > automake and silent-rules with $V being set to sth. else other than '1' > > or '0'. > > > > This is because of the following resulting Makefile code when using > > silent rules: > > > > AM_V_P = $(am__v_P_$(V)) > > am__v_P_ = $(am__v_P_$(AM_DEFAULT_VERBOSITY)) > > am__v_P_0 = false > > am__v_P_1 = : > > > > This breaks builds in environments such as e.g. the cross-compiling > > framework OpenWrt - which also uses $(V), however with values other than > > 1/0 (e.g. V=99, V={c,w,s}, etc.). > > Its not ideal (dirty), but you can work-around that by specifying > 'make AM_V_P=true' explicitly. Or the project itself can do something > like > > $ cat Makefile.am | grep ^AM_V_P > AM_V_P = test x0 = "x$(V)" > > .. when the project is known to use $V for its own purposes.
GNU Make supports: am__v_P_$(V) = $(am__v_P_$(AM_DEFAULT_VERBOSITY)) `make V='asldfj aksdfj lajsdf'` still works with this. but i don't know how portable this is. might be as portable as recursive make variables in general ? > > The way automake behaves here it claims that variable for its exclusive > > use. I don't mind automake using $(V), however if using such generic > > variable names, please don't make projects fail when $(V) is set to > > something other than 1 or 0. > > > > My proposal would be to enable verbose output, if $(V) is set to > > anything but '0' and to disable otherwise ($V is unset / set to '0'). > > That would probably require changing the semantics of $AM_V_P a bit, as it > now was always ':' or 'false'. But could be worth having fixed somehow. i don't think changing AM_V_P semantics is feasible. it's documented in the manual as having this behavior and has since automake-1.13 (for ~10 years). this variable is meant to be used by code written by users, not an internal Automake setting. -mike