bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #50376] Incompatibility in make versions - directory/ dependency no


From: Martin Dorey
Subject: [bug #50376] Incompatibility in make versions - directory/ dependency no longer match directory goal
Date: Fri, 24 Feb 2017 21:43:25 -0500 (EST)
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Follow-up Comment #1, bug #50376 (project make):

In 2010's make-3.82, which is where this behavior changed, and later releases,
the rule appears like this in make -p:


my_dir/hello.txt: | my_dir/


In make-3.81, it didn't have the trailing slash.  $(dir) still produced a
trailing slash there.  From printf debugging, I think the trailing slash was
being removed by the call to multi_glob in parse_prereqs, as it was then
called.  That was removed by this part:


diff --git a/file.c b/file.c
index a618beb..4e3bece 100644
--- a/file.c
+++ b/file.c
@@ -415,8 +415,7 @@ struct dep *
 parse_prereqs (char *p)
 {
   struct dep *new = (struct dep *)
-    multi_glob (parse_file_seq (&p, '|', sizeof (struct dep), 1),
-                sizeof (struct dep), 0);
+    parse_file_seq (&p, sizeof (struct dep), '|', NULL, 0);
 
   if (*p)
     {
@@ -426,8 +425,7 @@ parse_prereqs (char *p)
 
       ++p;
       ood = (struct dep *)
-        multi_glob (parse_file_seq (&p, '\0', sizeof (struct dep), 1),
-                    sizeof (struct dep), 0);
+        parse_file_seq (&p, sizeof (struct dep), '\0', NULL, 0);
 
       if (! new)
         new = ood;


... of this commit:

2009-09-16 17:07:01 +0000 address@hidden
(8f30b68871bde8687c7fcff8bac66e2b5765129e)

- Add xcalloc() and call it - Fix memory errors found by valgrind - Remove
multi_glob() and empower parse_file_seq() to do its job:   the goal here is to
remove the confusing reverse/re-reverse we do on   the file lists: needed for
future fixes. - Add a prefix arg to parse_file_seq() - Make concat() variadic
so it can take arbitrary #'s of strings


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]