possible bug in documentation for make
bug-make@gnu.org. 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 didnt 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 wasnt told in the documentation. 2nd problem: In most cases, of course, the order of processing the prerequisites doesnt 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 djgpps redir program to create a logfile (sml.log), to which the various compiler, assembler and linker messages are appended successively (redirs 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 prerequisitesim.d, coming last. Prerequisites are processed from right to left! Although this causes no problem, its a bit puzzling, and I cant find anything about it in the documentation. Id 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 Pt! Schon vom neuen WEB.DE MultiMessenger gehört? Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123 makefile Description: Binary data makelog.log Description: Binary data ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: possible bug in documentation for make
On Sat, 2008-10-25 at 22:42 +0200, Daniela Rütting wrote: 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. You are misunderstanding the situation. This has nothing to do with conditionals, and everything to do with precedence. The GNU make manual clearly specifies that variables set on the command line take precedence over ANY value set inside the makefile. Regardless of whether the setting of O was done inside a conditional or not, any value of O provided on the command line will be used instead. 2nd problem: 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! Again, you're misunderstanding what's going on. Make always tries to rebuild every makefile it processes, and that's including makefiles read in by include etc. In this case, make is trying to rebuild those included makefiles; it is NOT trying to remake those files because you have a target that lists them as dependencies. The order in which rebuilds its included makefiles is not defined anywhere. See the GNU make manual section How makefiles are remade for more details. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: possible bug in documentation for make
On Sat, Oct 25, 2008 at 1:42 PM, Daniela Rütting [EMAIL PROTECTED] wrote: ... 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. This has nothing to do with the conditionals and everything to do with mixing command-line and makefile assignments. To quote section 9.5 Overriding Variables of the make 3.81 manual: -- An argument that contains `=' specifies the value of a variable: `V=X' sets the value of the variable V to X. If you specify a value in this way, all ordinary assignments of the same variable in the makefile are ignored; we say they have been overridden by the command line argument. ... There is one way that the makefile can change a variable that you have overridden. This is to use the `override' directive, which is a line that looks like this: `override VARIABLE = VALUE' (*note The `override' Directive: Override Directive.). --y Indeed, if you use 'override' in your makefile, then it works as you expect. 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?) So you're using a version of make that has been obsolete for *6 years*, but haven't checked the new manual? (3.80 was released on 2002-10-03; 3.81 on 2006-04-01) Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: possible bug in documentation for make
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: [EMAIL PROTECTED] [EMAIL PROTECTED] To: bug-make@gnu.org bug-make@gnu.org Sent: Sat Oct 25 13:42:55 2008 Subject: possible bug in documentation for make bug-make@gnu.org. 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 Pt! Schon vom neuen WEB.DE MultiMessenger gehört? Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123 ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
