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 02:41:20PM -0400, Christos Zoulas wrote:
> | Try:
> | 
> | .MAKE.EXPAND_VARIABLES:= 0
> | 
> | BAR = 0
> | FOO = ${BAR}
> | 
> | and ask for the value of FOO.
> 
> That prints:
> 
>     ${BAR}
> 
> 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.

> | > I could do that, but then more complexity. N different ways to do the
> | > same thing.
> | 
> | But they are *not* the same thing. Expanded vs non-expanded is very
> | different.
> 
> Unexpanded is only useful for debugging; it should not be exposed as
> the default behavior. It was a design or coding mistake in the first
> place. Fixing it does not affect compatibility in an program-visible
> from. It is only user-visible. 

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.

> | > | (3) Revert -V behavior.
> | > 
> | > It does not matter. If I change in my Makefile:
> | > 
> | > FOO=${BAR}
> | > to:
> | > FOO:=${BAR}
> | > 
> | > Should the -V output change? What does an external program expect to
> | > do with ${BAR}?
> | 
> | Yes. I.e. figure out if the build rules support something like our PIE
> | flags etc. It is even documented to do that.
> 
> From the unexpanded variable that contains other variables internal
> to the Makefiles? That can change anytime since it is not part of
> the user-visible API?

I've seen worse ideas in the wild.

> | > And if I add -v to the mix, should I go and remove -dV? How about
> | > .MAKE.EXPAND_VARIABLES?
> | 
> | -dV was useless and should be again. The only purpose it served was to
> | override .MAKE.EXPAND_VARIABLES and even that could have been done by
> | setting the latter directly on the command line.
> 
> No, it can't... At least it does not seem to :-)
> 
> [2:40pm] 22>cat mk
> .MAKE.EXPAND_VARIABLES:=0
> BAR=1
> FOO=${BAR}
> [2:40pm] 23>make -f mk -D.MAKE.EXPAND_VARIABLES:=1 -V FOO
> ${BAR}

Wrong direction: make -V FOO .MAKE.EXPAND_VARIABLES=0 supersedes any
local assignment and gives the same behavior as -dV would.

Joerg


Home | Main Index | Thread Index | Old Index