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

 
 

bug #17752: target fails depending on order of prereqs

Submitted by:  None
Submitted on:  Thu 14 Sep 2006 08:59:42 PM UTC  
 
Severity: 3 - NormalItem Group: Bug
Status: FixedPrivacy: Public
Assigned to: Paul D. Smith <psmith>Open/Closed: Closed
Component Version: 3.81Operating System: POSIX-Based
Fixed Release: 3.82Triage Status: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

(Jump to the original submission 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>
Project AdministratorIn charge of this item.
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>
Project Member
Sat 13 Jun 2009 10:23:26 PM UTC, comment #5:

See bug #20006 as another instance

Paul D. Smith <psmith>
Project AdministratorIn charge of this item.
Wed 10 Jun 2009 02:50:09 AM UTC, comment #4:

See bug #18139 for another instance of this.

Paul D. Smith <psmith>
Project AdministratorIn charge of this item.
Wed 10 Jun 2009 02:35:13 AM UTC, comment #3:

See also bug #21670 for another instance of this.

Paul D. Smith <psmith>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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:

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>
Project AdministratorIn charge of this item.
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)

$(SRC):
echo 'main(){}' > $@

%.cp: %
cp $< $@

clean:
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?

Anonymous

 

(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 bosk (Posted a comment)
  • -unavailable- added by psmith (Posted a comment)
  •  

    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):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 28 Jul 2010 06:19:32 AM UTCpsmithFixed Release4.0=>3.82
    Wed 10 Jun 2009 02:30:38 AM UTCpsmithStatusNone=>Fixed
      Assigned toNone=>psmith
      Open/ClosedOpen=>Closed
      Fixed ReleaseNone=>4.0

    Back to the top


    Powered by Savane 3.1-cleanup