Re: possible bug in documentation for make

[Martin Dorey]

> last updated 04 April 2000, of `The GNU Make 
> Manual', for `make', Version 3.79.  I use: GNU Make 
> version 3.79.1

(Wow, that's pretty old skool.)

> It seems as if it is not possible to change the value 
> of a variable inside an ?ifeq? conditional that test 
> against that very variable

That would be a strange and distressing bug, but I would guess you'll find the 
documentation for the actual cause of the problem if you search for "override".

> The prerequisites are processed from left to right
> (as one would expect)

If your makefile doesn't specify an order (by making one prerequisite depend on 
another), then the order is deliberately undefined.  This gives make the 
freedom to, for example, build the prerequisites in parallel.  A -j switch to 
invoke that can often be beneficial on modern hardware.

Hope that helps, albeit indirectly.

----- Original Message -----
From: address@hidden <address@hidden>
To: address@hidden <address@hidden>
Sent: Sat Oct 25 13:42:55 2008
Subject: possible bug in documentation for make

<address@hidden>.

Hello,
I found two problems which I think are bugs in the documentation for ?make?:
1) Limitations of redefining a variable inside a conditional are not clear.
2) The order, in which prerequisites are processed, is not clear.
I refer to: Edition 0.55, last updated 04 April 2000, of `The GNU Make Manual', 
for `make', Version 3.79.
I use: GNU Make version 3.79.1, Built for i386-pc-msdosdjgpp
(not the newest version, I presume, but maybe no one mentioned the problem yet?)

1st problem: In an attempt to reduce tedious typing when defining a variable 
from the command line, I tried:
ifeq (max,$(O))
O = -O3 -fomit-frame-pointer -fno-unroll-loops
endif
ifeq (,$(O))
O = -O
endif
CXXFLAGS = -W -Wall $(O)
but this didn?t work. After typing ?make O=max? the value ?max? was passed 
straight to the compiler instead of being changed to ?-O3 -fomit-frame-pointer 
-fno-unroll-loops?. I had to use the more complex sequence
ifeq (max,$(O))
OPTIM = -O3 -fomit-frame-pointer -fno-unroll-loops
endif
ifeq (,$(O))
OPTIM = -O
endif
ifndef OPTIM
OPTIM = $(O)
endif
CXXFLAGS = -W -Wall $(OPTIM)
It seems as if it is not possible to change the value of a variable inside an 
?ifeq? conditional that test against that very variable, but I wasn?t told in 
the documentation.

2nd problem:
In most cases, of course, the order of processing the prerequisites doesn?t 
matter, but I have to struggle with the limitations of the DOS shell 
?command.com?. (Therefore several quirky ways to split long command lines in 
target ?sicher? of the appended makefile.) I use djgpp?s ?redir? program to 
create a logfile (?sml.log?), to which the various compiler, assembler and 
linker messages are appended successively (redir?s option -ea). So, an existing 
logfile, containing junk from earlier compilations, has to be removed _before_ 
any other action takes place. I achive this by putting the phony target ?klar? 
first in the prerequisite list of target ?all?. Phony target ?tst?, showing the 
final results of compilation, is put last, behind the real target.
So far, everything works fine. The prerequisites are processed from left to 
right (as one would expect). However, when updating the makefile itself (target 
?makefile?), the order seems to be the reverse. Command echoing (given in the 
appended file ?makelog.log?) shows re-generation of ?vid.d? first, followed by 
?schirm.d? etc., the first prerequisite??sim.d?, coming last. Prerequisites are 
processed from right to left!
Although this causes no problem, it?s a bit puzzling, and I can?t find anything 
about it in the documentation. I?d like to suggest that one or two sentences 
about this be added to the (otherwise very good, not to say exhaustive!) 
documentation. (Or maybe ?make? itself can be changed to a more consistent 
behaviour?)

Greetings
Bernhard Strowitzki


____________________________________________________________________
Psssst! Schon vom neuen WEB.DE MultiMessenger gehört? 
Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123