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

[anonymous]

URL:
  <http://savannah.gnu.org/bugs/?24164>

                 Summary: Improper Evaluation of Multiple Target rules with
Static Patterns
                 Project: make
            Submitted by: None
            Submitted on: Sat 30 Aug 2008 01:16:23 PM UTC
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
       Component Version: 3.81
        Operating System: Any
           Fixed Release: None

    _______________________________________________________

Details:

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



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Sat 30 Aug 2008 01:16:23 PM UTC  Name: maketest.tgz  Size: 985B   By:
None
TGZ file demonstrating the possible bug.
<http://savannah.gnu.org/bugs/download.php?file_id=16397>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?24164>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/