bug-make
[Top][All Lists]
Advanced

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

[bug #28456] Expansion of $$< is incorrect


From: Kirill Smelkov
Subject: [bug #28456] Expansion of $$< is incorrect
Date: Wed, 10 Feb 2010 16:16:04 +0000
User-agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.10 (like Gecko) (Debian)

Follow-up Comment #2, bug #28456 (project make):

Update:

$$< gets the same value as $$@ because of the following code fragment in
commands.c:

   if (file->cmds == default_file->cmds)
     /* This file got its commands from .DEFAULT.
        In this case $< is the same as address@hidden  */
     less = at;


With the following patch ...

diff --git a/commands.c b/commands.c
index 6c941f2..992b206 100644
--- a/commands.c
+++ b/commands.c
@@ -144,10 +144,12 @@ set_file_variables (struct file *file)
         break;
       }
 
+#if 0
   if (file->cmds == default_file->cmds)
     /* This file got its commands from .DEFAULT.
        In this case $< is the same as address@hidden  */
     less = at;
+#endif
 
 #define        DEFINE_VARIABLE(name, len, value) 
   (void) define_variable_for_file (name,len,value,o_automatic,0,file)


... I'm getting following results ($* was obvisouly added to the testcase):

$ touch 1.c && ../make -f bug-28456.mk 1.o
$@ : 1.o
$< : 
$^ : 
$+ : 
$? : 
$* : 1
--------
$@ : 1.o
$< : 1.c
$^ : 1.c
$+ : 1.c
$? : 1.c
$* : 1


Now we see that only target name $@ and stem $* are set. Only $* is
explicitely set in implicit.c:pattern_search() it seems:

              /* Update the stem value in $* for this rule.  */
              else if (!file_variables_set)
                {
                  define_variable_for_file (
                    "*", 1, file->stem, o_automatic, 0, file);
                  file_variables_set = 1;
                } 


Now the questions are:

 1. is it expected behaviour that $^ $+ $? are always empty on 
    second expansion? and,

 2. is it expected behaviour that $< is getting $@ for some 
    on second expansion for implicit rules like this?


Thanks beforehand,
Kirill

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?28456>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/





reply via email to

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