I would suggest to mention the current behavior in the manual, instead of making $(value ...) to emit a warning. The main motivation is backward compatibility.
In our project we widely use $(value N) to get arguments of 'call' that are assumed to be optional without raising a warning (I've just found about 100 lines where we use it to suppress the warning). And we also always use make with '
--warn-undefined-variables' flag too.
For example,
# Args:
# 1. A list to convert into a PATH variable.
# 2. (Optional) path separator to use. When empty, defaults to a colon.
PATHIFY = \
$(subst $(space),$(or $(value 2),$(colon)),$(strip $1))
This allows one to use $(call PATHIFY,foo bar) as well as $(call PATHIFY,bar baz,;).
Without using the 'value' function I would have to write something like:
$(subst $(space),$(if $(and $(filter-out undefined,$(flavor 2)),$2),$2,$(colon)),$(strip $1))
The latter looks ugly and it is also much slower if the function is assumed to be called often. And all these drawbacks would be needed only to suppress a warning.
Well, in other word, I think about 'value' function as a kind of an introspection facility. It is much like as 'flavor' or 'origin' functions, which do not generate a warning for undefined variables. So I wish to leave the current behavior as is and to describe it in the manual.
2012/3/14 R. Diez
<address@hidden>
Hi all:
Writing makefiles is hard enough, so I always enable option --warn-undefined-variables whenever I can.
I have recently realised that in GNU Make 3.81 the $(value ...) function does not warn as expected. That is, if I run this example makefile:
VAR_NAME := UNDEFINED_VARIABLE
all:
echo "$(UNDEFINED_VARIABLE)"
echo "$($(VAR_NAME))"
echo "$(value $(VAR_NAME))"
I get the following output:
Makefile:24: Warnung: undefinierte Variable »UNDEFINED_VARIABLE«
Makefile:24: Warnung: undefinierte Variable »UNDEFINED_VARIABLE«
echo ""
echo ""
echo ""
Is this an oversight? The manual does not mention any exceptions for --warn-undefined-variables, and I wish that $(value ...) warned too.
Please copy me on the answers, as I'm not subscribed to this list.
--
Best regards,
Eldar Sh. Abusalimov