bugmake - Bugs: bug #24164, Improper Evaluation of Multiple...

 
 

bug #24164: Improper Evaluation of Multiple Target rules with Static Patterns

Submitted by:  None
Submitted on:  Sat 30 Aug 2008 01:16:23 PM UTC  
 
Severity: 3 - NormalItem Group: Bug
Status: Not A BugPrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Component Version: 3.81Operating System: Any
Fixed Release: NoneTriage Status: None

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

Tue 02 Sep 2008 01:55:39 AM UTC, comment #3:

The followup comments are correct and this is expected and documented behavior; I'm closing this as "not a bug".

Paul D. Smith <psmith>
Project Administrator
Sat 30 Aug 2008 02:42:47 PM UTC, comment #2:

And furthermore, this is an extremely useful feature. Without it there is no other way to express to 'make' a rule where a single recipe generates multiple output files (and thus needs only be run once to generate them all.)

Anonymous
Sat 30 Aug 2008 02:38:48 PM UTC, comment #1:

The line about "rules with multiple targets are the same as multiple rules" doesn't apply to pattern rules. See section 10.5.1 of the documentation, which states:

Pattern rules may have more than one target. Unlike normal rules, this does not act as many different rules with the same prerequisites and recipe. If a pattern rule has multiple
targets, make knows that the rule’s recipe is responsible for making all of the targets. The recipe is executed only once to make all the targets. When searching for a pattern rule to
match a target, the target patterns of a rule other than the one that matches the target in need of a rule are incidental: make worries only about giving a recipe and prerequisites to
the file presently in question. However, when this file’s recipe is run, the other targets are marked as having been updated themselves.

Anonymous
Sat 30 Aug 2008 01:16:23 PM UTC, original submission:

I apologize in advance if this is a direct duplicate - I saw some bugs addressing the same general facility, but all seemed to deal with a more complex situation than the one I'm going to present. I do, however, suspect that they stem from the issue I'm going to attempt to demonstrate in the simplest case.

The documentation regarding rules with multiple targets (4.10 in the 'info' page) states that "A rule with multiple targets is equivalent to writing many rules, each with one target, and all identical aside from that." This seems intuitive, as the "Multiple Targets" facility is a means of consolidating common dependencies and operations into a single rule, saving space and eliminating duplication of code.

However, in the case that the "multiple targets" contain static patterns, they seem to be evaluated improperly. If the static pattern is matched against one of the targets, other targets declared in the same "multiple targets" rule with the same static pattern will be considered by that invocation of 'make' to be satisfied.

To demonstrate this, consider the following Makefiles (included as attachments):

'Makefile.problem'

a.% b.%:
@echo "$@: Rule Invoked with '$*'!"

'Makefile.control'

a.%:
@echo "$@: Rule Invoked with '$*'!"

b.%:
@echo "$@: Rule Invoked with '$*'!"

These Makefiles declare two rules, 'a.%' and 'b.%', both with the same associated action. 'Makefile.problem' consolidates these into a single "multiple target" rule, while 'Makefile.control' separates them out into two identical rules. However, invoking 'make' on these different files will produce noticeably different results:

> make -f Makefile.control a.0 b.0 b.1

a.0: Rule Invoked with '0'!
b.0: Rule Invoked with '0'!
b.1: Rule Invoked with '1'!

> make -f Makefile.problem a.0 b.0 b.1

a.0: Rule Invoked with '0'!
make: Nothing to be done for `b.0'.
b.1: Rule Invoked with '1'!

Continuing with this, any target provided on the command-line (and, in more complex Makefiles, named in dependencies) whose static pattern was matched by a different already-evaluated target in the same "multiple target" declaration will be considered, at runtime, to have been met, even though it wasn't.

I believe intuitively that the behavior of 'Makefile.control' is the correct one, and that 'Makefile.problem' demonstrates a bug. Otherwise, if this is not a bug, the documentation in 4.10 is incorrect, as combining the rules into a "multiple target" is not producing equivalent behavior.

I first encountered this issue on the 'make' packaged with Cygwin. However, I reproduced it for this report on Linux.

I believe that at least two other bugs listed here are complex manifestations of the underlying issue demonstrated in this bug:
#19108: http://savannah.gnu.org/bugs/?19108
#12078: http://savannah.gnu.org/bugs/?12078

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #16397:  maketest.tgz added by None (985B - application/x-compressed - TGZ file demonstrating the possible bug.)

 

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

    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 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 02 Sep 2008 01:55:39 AM UTCpsmithStatusNone=>Not A Bug
      Open/ClosedOpen=>Closed
    Sat 30 Aug 2008 01:16:23 PM UTCNoneAttached File-=>Added maketest.tgz, #16397

    Back to the top


    Powered by Savane 3.1-cleanup1