possible bug in gnu make regarding dereferenced constructed variable names used in conditionals

[Fred T. Hamster]

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. _____________

# this example makefile seems to demonstrate an incorrect evaluation of
# a dereferenced constructed variable name within an ifeq statement.
# the last echo shows what would be expected from evaluating the expression
# in question: $($(<:%=%_FLAGS)) where the first dependency is used to pull
# in some extra compilation flags from a variable named after that dependency.
# this usage was intended to allow overriding of the way individual objects
# are compiled in my c++ makefile system.
# is this a wrong expression usage or a bug?
# thanks...
# chris koeritz.

product.cpp_FLAGS = show_extra_info

all: clean_up_first product.exe

clean:
        @echo "cleaning up compilation products."
        @-rm product.o

clean_up_first: clean

product.exe: product.o
        @echo building product.exe

product.o: product.cpp
        @echo building product.o
        @echo frunkle >product.o
ifeq "$($(<:%=%_FLAGS))" ""
        @echo "flags evaluated to nothing!  this seems erroneous!"
else
        @echo "we had extra flags that we'd have done something with."
        @echo "this seems like the correct behavior."
endif
        @echo "the first part, the < evaluates to: $<"
        @echo "the flags replacement on that turns into: $(<:%=%_FLAGS)"
        @echo "the full dereference evaluates to: $($(<:%=%_FLAGS))"

//null file