Bug 52962 - Only one pattern-specific variable assignment per target
Only one pattern-specific variable assignment per target
Status: CLOSED DEFERRED
Product: Red Hat Raw Hide
Classification: Retired
Component: make (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Petr Machata
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-31 12:44 EDT by Jonathan Kamens
Modified: 2015-05-04 21:32 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-16 03:44:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to Make 3.79.1 to fix this bug (3.45 KB, patch)
2001-08-31 13:35 EDT, Jonathan Kamens
no flags Details | Diff
corrected 3.79.1 patch (3.44 KB, patch)
2001-08-31 15:31 EDT, Jonathan Kamens
no flags Details | Diff

  None (edit)
Description Jonathan Kamens 2001-08-31 12:44:42 EDT
Date: Fri, 31 Aug 2001 12:38:26 -0400
From: Jonathan Kamens <jik@kamens.brookline.ma.us>
To: bug-make@gnu.org
Subject: Only one pattern-specific variable assignment per target?

Put this in a Makefile:

  foo.%bc: FIRST=first
  foo.a%c: SECOND=second
  foo.abc: THIRD=third

  foo.abc: ; @echo $(FIRST) $(SECOND) $(THIRD)

Run "make".  I believe that it *should* print "first second third",
but instead it prints "first third".

If you swap the order of the first and second lines, it instead prints
"second third".

I've observed this behavior in make 3.77, 3.78.1 and 3.79.1.

This is because Make only interprets one pattern-specific variable
rule for each target.  This behavior does not seem to be documented,
and I don't think it's correct.  The patch below fixes it, I believe.
Please let me know if you think this is an appropriate fix.

  Jonathan Kamens

Index: expand.c
===================================================================
RCS file: /projects/systems/cvs-root/gnu/make/expand.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 expand.c
--- expand.c	1999/10/20 21:57:49	1.1.1.2
+++ expand.c	2001/08/31 16:35:50
@@ -450,13 +450,13 @@
   /* See if there's a pattern-specific variable struct for this target. 
*/
   if (!file->pat_searched)
     {
-      file->patvar = lookup_pattern_var(file->name);
+      struct pattern_var *p = NULL;
+      while (p = lookup_pattern_var(file->name, p))
+        {
+          p->vars->next = file->variables->next;
+          file->variables->next = p->vars;
+        }
       file->pat_searched = 1;
-    }
-  if (file->patvar != 0)
-    {
-      file->patvar->vars->next = fnext;
-      file->variables->next = file->patvar->vars;
     }
   result = variable_expand (line);
   current_variable_set_list = save;
Index: filedef.h
===================================================================
RCS file: /projects/systems/cvs-root/gnu/make/filedef.h,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 filedef.h
--- filedef.h	1999/10/20 21:57:50	1.1.1.2
+++ filedef.h	2001/08/31 16:11:50
@@ -56,10 +56,6 @@
        the same file.  Otherwise this is null.  */
     struct file *double_colon;
 
-    /* Pattern-specific variable reference for this target, or null if
there
-       isn't one.  Also see the pat_searched flag, below.  */
-    struct pattern_var *patvar;
-
     short int update_status;	/* Status of the last attempt to update,
 				   or -1 if none has been made.  */
 
Index: rule.c
===================================================================
RCS file: /projects/systems/cvs-root/gnu/make/rule.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 rule.c
--- rule.c	1999/10/20 21:57:49	1.1.1.2
+++ rule.c	2001/08/31 16:30:03
@@ -575,16 +575,17 @@
   return p;
 }
 
-/* Look up a target in the pattern-specific variable list.  */
+/* Look up a target in the pattern-specific variable list, optionally
+   starting after the last target we looked at. */
 
 struct pattern_var *
-lookup_pattern_var (target)
+lookup_pattern_var (target, p)
      char *target;
+     struct pattern_var *p;
 {
-  struct pattern_var *p;
   unsigned int targlen = strlen(target);
 
-  for (p = pattern_vars; p != 0; p = p->next)
+  for (p = p ? p->next : pattern_vars; p != 0; p = p->next)
     {
       char *stem;
       unsigned int stemlen;
Index: rule.h
===================================================================
RCS file: /projects/systems/cvs-root/gnu/make/rule.h,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 rule.h
--- rule.h	1999/10/20 21:57:50	1.1.1.2
+++ rule.h	2001/08/31 16:04:26
@@ -62,7 +62,8 @@
 extern void install_pattern_rule PARAMS ((struct pspec *p, int terminal));
 extern int new_pattern_rule PARAMS ((struct rule *rule, int override));
 extern struct pattern_var *create_pattern_var PARAMS ((char *target, char
*suffix));
-extern struct pattern_var *lookup_pattern_var PARAMS ((char *target));
+extern struct pattern_var *lookup_pattern_var PARAMS ((char *target,
+                                                       struct pattern_var
*p));
 extern void count_implicit_rule_limits PARAMS ((void));
 extern void convert_to_pattern PARAMS ((void));
 extern void create_pattern_rule PARAMS ((char **targets,
Comment 1 Jonathan Kamens 2001-08-31 13:34:55 EDT
I just discovered that the patch I submitted is valid against 3.78.1 but not
against 3.79.1.  I'll attach an equivalent patch for 3.79.1.
Comment 2 Jonathan Kamens 2001-08-31 13:35:18 EDT
Created attachment 30374 [details]
patch to Make 3.79.1 to fix this bug
Comment 3 Jonathan Kamens 2001-08-31 15:30:41 EDT
Sigh.  My 3.79.1 patch was wrong.  I'll attach another one.
Comment 4 Jonathan Kamens 2001-08-31 15:31:01 EDT
Created attachment 30396 [details]
corrected 3.79.1 patch
Comment 5 Petr Machata 2006-03-16 03:44:12 EST
It's in CVS.  I will push it to rawhide when fc5 comes out, and most probably
for fc4/5 if the patch is stable.  I'm closing the bug, as most probably you
aren't interested anymore, but any comments are welcome.
Comment 6 Jonathan Kamens 2006-03-16 07:44:10 EST
Wow, blast from the past :-).
Did you upstream the patch as well?
Comment 7 Petr Machata 2006-03-17 04:40:23 EST
Surprising that you still use that email ;)
In upstream, they have their own fix, so I didn't send this one.

Note You need to log in before you can comment on or make changes to this bug.