bin/64327: [PATCH] make(1): document surprising behaviour of assign with expansion

[Oliver Eikemeier]

The following reply was made to PR bin/64327; it has been noted by GNATS.

From: Oliver Eikemeier <eikemeier at fillmore-labs.com>
To: Ruslan Ermilov <ru at freebsd.org>
Cc: FreeBSD-gnats-submit at freebsd.org
Subject: Re: bin/64327: [PATCH] make(1): document surprising behaviour of
 assign with expansion
Date: Tue, 16 Mar 2004 15:35:17 +0100

 Ruslan Ermilov wrote:
 
 > On Tue, Mar 16, 2004 at 02:58:35PM +0100, Oliver Eikemeier wrote:
 > [...]
 > 
 >>>Perhaps you could convert it to fit the manpage?  Definitely we shouldn't 
 >>>put
 >>>it in the BUGS section.
 >>
 >>I though so. What should I use: HISTORY, CAVEATS, IMPLEMENTATION NOTES or 
 >>something else?
 > 
 > I prefer to just document this behavior of the := assignment.
 
 VARIABLE ASSIGNMENTS then. Perhaps after
 
   Variable substitution occurs at two distinct times, depending on where
   the variable is being used.  Variables in dependency lines are expanded
   as the line is read.  Variables in shell commands are expanded when the
   shell command is executed.
 
 >>Undefined variables are left untouched when assigned with expansion.
 > 
 > Undefined variables can't be "left", as they don't exist at all.  Instead,
 > saying something along the code comments, like "expanded variables can be
 > undefined, in this case their expansion is attempted later", and give an
 > example from the code.
 
 I don't think this is an good example:
 
 - I think it doesn't illustrate the pitfall clearly enough
 
 - I do not really want to encourage anyone to use this feature. It looks
   like this feature is a little too tricky, and AFAIK other makes don't
   behave this way, so Makefiles get highly unportable and are difficult
   to follow for people used to other behaviour.
   While I know that this is BSD make and we have to keep this because of
   compatibility reasons, I'm not really sure of the value of this
   construct, the example should be rewritten
     CFLAGS = -I.. $(.INCLUDES)
   anyway.
 
 Could you come up with another example? I'm sorry if I am too intractable,
 but I more like to show the pitfalls (like the example in the BUGS section),
 than to point out a value which I can't see.
 
 Oliver