lmi
[Top][All Lists]
Advanced

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

Re: [lmi] make: chaining target-specific, immediately-expanded variables


From: Vadim Zeitlin
Subject: Re: [lmi] make: chaining target-specific, immediately-expanded variables
Date: Sat, 2 Jul 2022 19:14:04 +0200

On Sat, 2 Jul 2022 14:55:53 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> With this makefile:
GC> 
GC> --8<----8<-- eraseme.make --8<----8<--
GC> target1:
GC>     @echo xyz   = "$(xyz)"
GC>     @echo flags = "$(flags)"
GC>     touch $@
GC> 
GC> target2:
GC>     @echo xyz   = "$(xyz)"
GC>     @echo flags = "$(flags)"
GC>     touch $@
GC> 
GC> xyz := default
GC> 
GC> target2: xyz += nondefault
GC> 
GC> flags := $(xyz)
GC> --8<----8<-- eraseme.make --8<----8<--
GC> 
GC> what does
GC>   make -f eraseme.make target2
GC> echo?

 I'd expect "xyz" to have the value "default nondefault" and "flags" to
have the value "default" simply because "flags" uses the value of "xyz"
evaluated when it is defined and it can't use target-specific value there
because "flags" could be used by another target too.
        
GC> I had expected that 'xyz' would be "default nondefault",
GC> and that 'flags' would have the same value as 'xyz'.

 This would be very surprising, IMO. What if you added a line

        target1: xyz += bloordyblop

to your example makefile, would you expect flags to contain both additions
even if xyz itself can never have the value combining them?

GC> This minimalistic example demonstrates a latent defect in
GC> 'compiler_gcc.make', whose $(REQUIRED_COMPILER_FLAGS) is
GC> immediately expanded. If $(optimization_flag) is added to
GC> its definition instead of to $(CXXFLAGS), then this
GC> target-specific value:
GC> 
GC> $(product_file_sources): optimization_flag += $(product_file_flags)
GC> 
GC> is disregarded.

 Understanding the example above in isolation is, of course, quite
different from being able to detect problems such as this one, which is why
I think it's important to keep makefiles as simple as possible. The fact
that you can do everything with GNU make doesn't mean you should...

 More concretely, my tentative conclusion here would be to avoid using
target-specific variables for non-terminal variables.

 Regards,
VZ

Attachment: pgp24IyK1E_C6.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]