[Top][All Lists]

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

Re: possible bug in documentation for make

From: Paul Smith
Subject: Re: possible bug in documentation for make
Date: Sat, 25 Oct 2008 18:03:59 -0400

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
 Paul D. Smith <address@hidden>          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

reply via email to

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