bugmake - Bugs: bug #27497, Later double-colon rules don't...

 
 

bug #27497: Later double-colon rules don't fire if earlier ones think target is up to date

Submitter:  None
Submitted:  Tue 22 Sep 2009 03:08:01 PM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  Not A Bug Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  3.81 Operating System:  POSIX-Based
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 22 Sep 2009 06:28:58 PM UTC, comment #2: 

Ah, I see.

It would be nice if the documentation were clearer here. In particular, the "Double-Colon Rules" section could explain the other meaning of the double-colon, and say when it applies (which is not mentioned explicitly anywhere that I can see).

Currently the "Double-Colon Rules" section flatly contradicts various other parts of the manual in as far as it relates to pattern rules.

Anonymous
Tue 22 Sep 2009 03:50:56 PM UTC, comment #1: 

Make is behaving exactly as it should here.  You are confused because you think that a double-colon in a pattern rule behaves the same way as a double-colon in an explicit rule... but it doesn't.  A rule like "%.a :: %.c" is very different than "foo.a :: foo.c".  See the section "Match-Anything Pattern Rules" in the GNU make manual.

Pattern rules don't need double-colon capabilities because they work like that all the time.  For pattern rules, if make cannot use the pattern (that is either the target doesn't match the pattern, or the target does match but the prerequisites don't exist and make doesn't know how to build them) then it skips that pattern and tries the next one.

The "order matters" rule is a feature.  From the GNU make manual section "Introduction to Pattern Rules", you'll see:

>   The order in which pattern rules appear in the makefile is
> important since this is the order in which they are
> considered.  Of equally applicable rules, only the first one
> found is used.

Paul D. Smith <psmith>
Group administrator
Tue 22 Sep 2009 03:08:01 PM UTC, original submission:  

I have a collection of files, %.a and %.b, and I want to generate %.c from them. If %.b exists, I want %.c to depend on %.a and %.b, and otherwise I want %.c to depend on only %.a. I do this:

all : foo.c

%.c :: %.a %.b
        echo %.a %.b > $@
        touch $@

%.c :: %.a
        echo %.a > $@

This works fine (except that if %.b is deleted, %.c isn't rebuilt):

$ touch foo.a
$ make
echo %.a > foo.c
$ touch foo.b
$ make
echo %.a %.b > foo.c
$

However, if I reverse the order of the rules:

all : foo.c

%.c :: %.a
        echo %.a > $@

%.c :: %.a %.b
        echo %.a %.b > $@
        touch $@

Then it no longer works:

$ touch foo.a
$ make
echo %.a > foo.c
$ touch foo.b
$ make
make: Nothing to be done for `all'.
$

Now, the first rule hasn't fired and updated foo.c, and the second rule says foo.c is not up-to-date, so the second rule's actions should be run, but they aren't.


$ make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for x86_64-redhat-linux-gnu

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #18754:  WorkingMakefile added by None (74B - application/octet-stream - Example makefiles showing the problem)
file #18753:  BrokenMakefile added by None (74B - application/octet-stream - Example makefiles showing the problem)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-09-22 psmith StatusNone Not A Bug
        Open/ClosedOpen Closed
    2009-09-22 None Attached File- Added BrokenMakefile, #18753
        Attached File- Added WorkingMakefile, #18754

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code