Date: Tue, 16 Mar 2004 06:40:15 -0800 (PST) From: Oliver Eikemeier <eikemeier@fillmore-labs.com> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/64327: [PATCH] make(1): document surprising behaviour of assign with expansion Message-ID: <200403161440.i2GEeFcS010947@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/64327; it has been noted by GNATS. From: Oliver Eikemeier <eikemeier@fillmore-labs.com> To: Ruslan Ermilov <ru@freebsd.org> Cc: FreeBSD-gnats-submit@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403161440.i2GEeFcS010947>