tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: make -V default behavior change



On Mon, Jun 19, 2017 at 03:21:35PM -0400, Christos Zoulas wrote:
> On Jun 19,  8:59pm, joerg%bec.de@localhost (Joerg Sonnenberger) wrote:
> -- Subject: Re: make -V default behavior change
> 
> | > same as before. Nothing changed. -V defaults to expand as it defaulted
> | > before not to expand. -dV and .MAKE.EXPAND_VARIABLES overrides the
> | > behavior. Yes, this is too complicated but I did not change it; it was
> | > there committed as a result of the 2002 conversation.
> | 
> | But that's the point: "-V FOO" does not deterministically expand FOO --
> | it still depends on outside magic.
> 
> My understanding is that the outside magic is:
> 
> 1. -dV 
> 2. .MAKE.EXPAND_VARIABLES
> 
> which is the same as before. Right?

Yes, so your change doesn't really fix anything. You still have to deal
with someone being clever and putting .MAKE.EXPAND_VARIABLES somewhere,
so the option does not "always expand the variable".

> | It's called introspection. Even if it is just for debugging, doesn't
> | mean that existing scripts don't depend on it for for automatic
> | debugging.
> 
> Debugging output is exactly that: to aid in debugging. You are advocating
> to keeping the default output to be the debugging output. We already using
> ${MAKE} -V '$${SRCS}' in our Makefiles just because the default was wrong
> to work around it. We can still fix any debug scripts by adding -dV; it
> works the same way before and after the change.

I always considered -V a debug aid first and I haven't seen a very
convincing argument otherwise. I'm almost inclined to write a
"smart-show.sh" script that determines all the variables the expansion
is based on and prints them. Would be quite handy to figure out where
CFLAGS gets it current value given the various expansions going on.

> 
> | I've seen worse ideas in the wild.
> 
> And you are advocating keeping the default behavior to cater to the
> bad ideas? If anything you should advocate for breaking them on purpose
> to discourage them :-)

No, I'm advocating for introducing a well defined flag different from
the existing interface for doing the operation "show me the expanded
value of this variable", something that isn't easily done with the
existing interface nor provided by your change. If you have to retrain
fingers anyway, it helps to at least make sure that the resulting
knowledge works consistently.

Joerg


Home | Main Index | Thread Index | Old Index