On Jun 18, 7:01pm, jo...@bec.de (Joerg Sonnenberger) wrote:
-- Subject: Re: CVS commit: src/usr.bin/make
| On Sat, Jun 17, 2017 at 10:40:25PM -0400, Christos Zoulas wrote:
| > On Jun 18, 12:36am, jo...@bec.de (Joerg Sonnenberger) wrote:
| > -- Subject: Re: CVS commit: src/usr.bin/make
| >
| > | Please do not unilaterally change behavior. Especially if it has been
| > | discussed in the past. This is rude at best and not everyone shares your
| > | opinion.
| >
| > Please explain the use case (aside for looking at the internal
representation
| > of a variable). For example, if .OBJDIR, LIB, etc. ended up unexpanded, many
| > things would break. I just don't think it is useful to be the default, and
| > using -V '${var}' to get it to expand is counter-intuitive. Why should it
| > behave differently in the first place?
|
| They haven't been expanded for years, if ever. You have broken any user
| of the unexpanded variables already. ${var} is a pretty intuitive
| semantics for "show me this expression". It even works for complex
| expressions involving modifiers. Your change has increased the
| complexity of the argument format without providing any new value. It
| has broken compatibility. It was not discussed. I think those are more
| than enough reasons to ask for a revert.
This is not what I asked; I asked for a use case. The reason we have not
made this change sooner is because the majority of the variables produce
already expanded values. I don't think that it is reasonable for someone
in a Makefile to have to write:
foo!=${MAKE} -V '$${var}'
which is the common use case to get the expanded value. Again, what
is the use case? I don't buy the argument that this will break
compatibility since the majority of the variables produce the same
results. The users also expect the expanded value, not an intermediate
representation (which is again non portable since it can change
anytime; so we can't depend on its form to parse it). Bottom line:
please explain the use case (aside from debugging). I.e.
1. What needs the intermediate representation, and how it can be used?
2. When is the intermediate representation preferable?
christos
