bugmake - Bugs: bug #28456, Expansion of $$< is incorrect

 
 

bug #28456: Expansion of $$< is incorrect

Submitted by:  Ian Lynagh <igloo>
Submitted on:  Fri 01 Jan 2010 01:37:37 AM UTC  
 
Severity: 3 - NormalItem Group: Bug
Status: NonePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Component Version: 3.81Operating System: Any
Fixed Release: NoneTriage Status: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sat 16 Oct 2010 03:06:50 AM UTC, comment #5:

I'm confirming the bug on a Ubuntu 9.10 i386 host.

Curiously, this particular bug also triggers circular dependencies. More surprising, the test case is simply the snippet found straight in the info page (make.info, section 3.10, "Secondary Expansion of Implicit Rules").

The snippet is (blank lines ommited):

.SECONDEXPANSION:
foo: bar
foo foz: fo%: bo%
%oo: $$< $$^ $$+ $$*

One might have to "touch bar boo f" before running make. The output is:

make: Circular foo <- foo dependency dropped.

I hope this example will draw more attention to the issue.

Cheers,
Alek

Anonymous
Mon 20 Sep 2010 05:43:06 PM UTC, comment #4:

See also duplicate bug #31087

Paul D. Smith <psmith>
Project Administrator
Wed 10 Feb 2010 04:34:42 PM UTC, comment #3:

Update:

It seems current make behaviour is inconsisten with its manual. I quote `Secondary Expansion of Implicit Rules':

"""
As `make' searches for an implicit rule, it substitutes the stem and
then performs secondary expansion for every rule with a matching target
pattern. The value of the automatic variables is derived in the same
fashion as for static pattern rules. As an example:

.SECONDEXPANSION:

foo: bar

foo foz: fo%: bo%

%oo: $$< $$^ $$+ $$*

When the implicit rule is tried for target `foo', `$$<' expands to
`bar', `$$^' expands to `bar boo', `$$+' also expands to `bar boo', and
`$$*' expands to `f'.
"""

So let's verify that:

$ cat se-manual.mk
.SECONDEXPANSION:

foo: bar

foo foz: fo%: bo%

show-vars = \
$(info $$@ : $@) \
$(info $$< : $<) \
$(info $$^ : $^) \
$(info $$+ : $+) \
$(info $$* : $*) \

%oo: $$(show-vars)
touch $@

$ touch bar && make -f se-manual.mk foo
$@ : foo
$< : foo
$^ : bar boo
$+ : bar boo
$* : f
$@ : boo
$< : boo
$^ :
$+ :
$* : b
touch foo

Take a closer look to first 5 output lines starting with `$@ : foo'. The manual says "When the implicit rule is tried for
target `foo', `$$<' expands to `bar', `$$^' expands to `bar
boo', `$$+' also expands to `bar boo', and `$$*' expands to `f'"

But it seems we have $$< = foo (!= bar).

Could please anyone clarify, what is the right behaviour and how (if whether) we need to fix it.

Thanks beforehand,
Kirill

Kirill Smelkov <kirr>
Wed 10 Feb 2010 04:16:04 PM UTC, comment #2:

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 $@. */
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 $@. */
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

Kirill Smelkov <kirr>
Wed 10 Feb 2010 12:53:29 PM UTC, comment #1:

I think I was also beaten by this. Consider:

---- 8< ----

$ cat bug-28456.mk
.SUFFIXES:

all : 1.o

show-vars = \
$(info $$@ : $@) \
$(info $$< : $<) \
$(info $$^ : $^) \
$(info $$+ : $+) \
$(info $$? : $?) \

.SECONDEXPANSION:

%.o : %.c $$(show-vars)
$(info --------)
$(show-vars)
$(CC) $(CFLAGS) -o $@ -c $<

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

---- 8< ----

So as you can see $$< is wrongly second-expanded to 1.o (instead of 1.c), and $$^, $$+, $$? are second-expanded to empty strings (instead of 1.c too).

Tested on make 3.81 and latest CVS (3.81.90; last commit on Fri Dec 11 15:55:16 2009 +0000 by eliz)

Thanks beforehand,
Kirill

Kirill Smelkov <kirr>
Fri 01 Jan 2010 01:37:37 AM UTC, original submission:

I was trying out the example in the "Secondary Expansion" part of the manual, and the expansion of $$< seems to be wrong in both 3.81 and CVS. For example, this Makefile:

Gives this output:

i.e. $$< appears to have been expanded to "foo", whereas I would expect it to be expanded to the empty string.

Ian Lynagh <igloo>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by psmith (Posted a comment)
  • -unavailable- added by kirr (Posted a comment)
  • -unavailable- added by igloo (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    No Changes Have Been Made to This Item

    Back to the top


    Powered by Savane 3.1-cleanup