bugmake - Bugs: bug #17752, target fails depending on order of...


bug #17752: target fails depending on order of prereqs

Submitter:  None
Submitted:  Thu 14 Sep 2006 08:59:42 PM UTC
Severity:  3 - Normal Item Group:  Bug
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  3.81 Operating System:  POSIX-Based
Fixed Release:  3.82 Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Sat 01 Aug 2009 07:42:41 PM UTC, comment #7: 

I believe bug #21771 is another example of this.

Paul D. Smith <psmith>
Group administrator
Sun 19 Jul 2009 12:36:00 AM UTC, comment #6: 

I tend to agree, my change caused quite a few regressions according to the GNU make documentation. However, I also don't think the original 3.80 behavior is correct. That "ought to exist" is a misnomer. Who said that just because a file is made a prerequisite of some target, it ought to exist? What if this target is not used in this compilation episode? A makefile can contain different sets of rules that are used to build different things at the request of the user. Why mentioning the file as a prerequisite in one set of rules should affect the other set?

I agree that the correct way would be to actually try to build the file (or make sure that it can be built) be it via an implicit rule, DEFAULT, etc. Not sure how easy it will be to implement something like this, though. In other words, before deciding on an implicit rule, we need to make sure all the prerequisites that came from this rule either exist or can actually be built.

Should I open a separate bug report for this?

Boris Kolpackov <bosk>
Group Member
Sat 13 Jun 2009 10:23:26 PM UTC, comment #5: 

See bug #20006 as another instance

Paul D. Smith <psmith>
Group administrator
Wed 10 Jun 2009 02:50:09 AM UTC, comment #4: 

See bug #18139 for another instance of this.

Paul D. Smith <psmith>
Group administrator
Wed 10 Jun 2009 02:35:13 AM UTC, comment #3: 

See also bug #21670 for another instance of this.

Paul D. Smith <psmith>
Group administrator
Wed 10 Jun 2009 02:30:38 AM UTC, comment #2: 

I've found at least one other bug that seems to be this same change, so I'm backing out this change at least for now to have the behavior agree with the manual again.

We can revisit to decide if there's an enhancement we want to make here, or a change to the behavior (but this would need to be documented), or what.

I've added a test to the test suite to keep track of the existing behavior so we'll know if we change it again in the future.

Paul D. Smith <psmith>
Group administrator
Tue 09 Jun 2009 07:24:33 PM UTC, comment #1: 

Hm.  I looked at this.  It looks like a bug to me.  I traced it down to a change by BorisK on 21 Sep 2004:

  • implicit.c (pattern_search): When considering an implicit rule's

prerequisite check that it is actually a target rather then
just an entry in the file hashtable.

By making this change we require that all prerequisites be targets at the time we do the implicit rule search, which is clearly not true for your situation as the prerequisite (foo) is not a target until after you match the implicit rule.  To see why this change was made I undid it, then ran the test suite and the reason for the change became obvious: the goal is to allow implicit rule searches to skip past explicit files that do not exist, to get to an implicit rule that CAN be made.  the misc/general4 test, for example, uses this makefile:

$ touch bar
$ cat makefile
%.foo : baz ; @echo done $<
%.foo : bar ; @echo done $<
fox: baz

For this makefile make 3.80 doesn't do what we'd like, which is skip the first implicit rule (because baz doesn't exist and cannot be remade) and find the second implicit rule, where "bar" does exist, and print "done bar".  With 3.81 we do get that behavior, but with 3.80 we don't: we get an error that baz does not exist and cannot be remade.

Looking at the GNU make manual section "Implicit Rule Search Algorithm", we see why 3.80 behaves the way it does; by step 5c make chooses the first implicit rule where all prerequisites exists or ought to exist.  Because of the "fox: baz" line above, mentioning "baz" as a prerequisite on an explicit rule, "baz" is considered a file that "ought to exist", and so make chooses the first rule and fails, even though if it skipped to the second rule it could succeed.

The change Boris added, while enabling this case to succeed, broke the case you're bringing up here and possibly some other problems with implicit rule chaining that have been reported (I'll have to look at them carefully to see).  Also, the behavior of make doesn't match the manual any longer since the meaning of "ought to exist" has been changed.

So, I'm tempted to revert the change.  I'm not adverse to modifying the chaining algorithm to allow make to be smarter about the case Boris is concerned about, but this simple change is too simple.  To really fix this we'd need to try to build the prerequisites and see if it fails, not just test to see if they're targets or not.  I suspect, though, that the reason rule 5c is there is to prune the decision tree to be manageable, and that if we extend that rule to allow searching to decide whether files that "ought to exist" really DO exist (or can be made to exist) the possible outcomes will explode and make will become pretty slow.

I'll discuss this with Boris.

Paul D. Smith <psmith>
Group administrator
Thu 14 Sep 2006 08:59:42 PM UTC, original submission:  

Given this makefile:

COPY = foo.cp
BIN = foo

SRC = $(COPY:.cp=.c)

allworks: $(BIN) $(COPY)

allbroken: $(COPY) $(BIN)

echo 'main(){}' > $@

%.cp: %
cp $< $@

rm -rf $(SRC) $(COPY) $(BIN)

make allworks -- works on 3.81
make allbroken -- works on 3.80 but does not on 3.81

Is this a feature or bug?



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

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by bosk (Posted a comment)
  • -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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-28 psmith Fixed Release4.0 3.82
    2009-06-10 psmith StatusNone Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.0

    Back to the top

    Powered by Savane 3.13-7b9d.
    Corresponding source code