[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: possible bug in gnu make regarding dereferenced constructed variable
From: |
Martin Dorey |
Subject: |
RE: possible bug in gnu make regarding dereferenced constructed variable names used in conditionals |
Date: |
Sun, 6 Aug 2006 12:19:29 -0700 |
Thanks for your polite report. I think you've been bitten by one of
make's design quirks, documented by this section in the manual ($< is an
"automatic" variable):
Conditional Statements
----------------------
All instances of conditional syntax are parsed immediately, in their
entirety; this includes the `ifdef', `ifeq', `ifndef', and `ifneq'
forms. Of course this means that automatic variables cannot be used
in
conditional statements, as automatic variables are not set until the
command script for that rule is invoked. If you need to use automatic
variables in a conditional you _must_ use shell conditional syntax, in
your command script proper, for these tests, not `make' conditionals.
There are solutions other than using shell conditions. For example, you
can have several alternate rule bodies defined in variables and then
choose which rule to execute based on the value of an automatic
variable. Rules like this aren't uncommon:
target: prerequisite
$(COMPILE$(suffix $<)) $< -o $@
Hope that helps.
-------------------------------------
Martin's Outlook, BlueArc Engineering
-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of Fred
T. Hamster
Sent: Saturday, August 05, 2006 10:57
To: address@hidden
Subject: possible bug in gnu make regarding dereferenced constructed
variable names used in conditionals
dear gnu,
thanks for developing gnu make. i rely on it daily.
i was trying to extend my makefiles recently and found what looks to
me like a bug. i'm including an example makefile that's hopefully
stripped down enough.
what i was expecting is that a variable name could be constructed
within a variable expression and then dereferenced. in one case this
seems to work great (in an echo statement), but in another case (an ifeq
conditional), it seems to be treated incorrectly as null when it should
have contents.
i have GNU Make 3.80 running on a suse 10.0 linux system (x86). i've
also tried it and gotten the same results with version 3.81 on a debian
sarge system.
here's the makefile output from the sample makefile:
-----------
address@hidden $ make
cleaning up compilation products.
building product.o
flags evaluated to nothing! this seems erroneous!
the first part, the < evaluates to: product.cpp
the flags replacement on that turns into: product.cpp_FLAGS
the full dereference evaluates to: show_extra_info
building product.exe
-----------
the expected print-out was not seen; instead the "seems erroneous"
message above gets shown.
this comes from the conditional in the example makefile, where instead
i would expect the other message to be shown:
-----------
we had extra flags that we'd have done something with.
this seems like the correct behavior.
-----------
the last print out in the make run is the fully evaluated expression
and it is not an empty string (it evaluated to "show_extra_info"), yet
the ifeq conditional claims that the expression is equal to null. that
seems incorrect.
while trying to figure out what was going on, i tried both ifeq and
ifneq to compare against a null value. they both consistently seem to
return the opposite result from the expected one. first i questioned my
sanity and understanding of boolean algebra. then i questioned whether
this type of dereferenced variable is intended to be supported or not,
but the echo statement later in the makefile shows the expression that
i'm expecting from the construct.
i'm including the example makefile that uses the dereferenced variable
approach plus the basically empty source file used in the makefile.
thanks very much if you could look into this. certainly further
thanks are due if you could let me know if it's a bug or not. in
general, thanks very much for the gnu software.
-chris koeritz
aka fred t. hamster (internet pseudonym)
--
_______ chosen by the Nechung Oracle Program [ http://gruntose.com/ ]
_______
,,ggddY"""Ybbgg,,
,agd888b,_ "Y8, ___`""Ybga,
,gdP""88888888baa,.""8b "888g,
,dP" ]888888888P' "Y `888Yb,
,dP" ,88888888P" db, "8P""Yb,
,8" ,888888888b, d8888a "8,
,8' d88888888888,88P"' a, `8,
,8' 88888888888888PP" "" `8,
d' I88888888888P" `b
8 `8"88P""Y8P' 8
8 Y 8[ _ " 8
8 "Y8d8b "Y a 8
8 `""8d, __ 8
Y, `"8bd888b, ,P
`8, ,d8888888baaa ,8'
`8, 888888888888' ,8'
`8a "8888888888I a8'
`Yba `Y8888888P' adP'
"Yba `888888P' adY"
`"Yba, d8888P" ,adP"' Normand Veilleux
`"Y8baa, ,d888P,ad8P"' from
``""YYba8888P""'' Spaceship Earth
_____________ not necessarily my opinions, not necessarily not.
_____________
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- RE: possible bug in gnu make regarding dereferenced constructed variable names used in conditionals,
Martin Dorey <=