[dgoncha...@users.sf.net: [PATCH] uninitialized variable in parse_file_seq]

[Dmitry Goncharov]

glob/glob.c touches this variable when the user passes a pattern with a
trailing slash to wildcard.

regards, Dmitry


diff --git a/src/read.c b/src/read.c
index db1a42d..2e44d5e 100644
--- a/src/read.c
+++ b/src/read.c
@@ -3065,6 +3065,7 @@ parse_file_seq (char **stringp, unsigned int size, int 
stopmap,
   glob_t gl;
   char *tp;
   int findmap = stopmap|MAP_VMSCOMMA|MAP_BLANK|MAP_NUL;
+  gl.gl_offs = 0;
 
   /* Always stop on NUL.  */
   stopmap |= MAP_NUL;

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[PATCH] add wildcard tests

[Dmitry Goncharov]

These are wildcard tests that pass patterns with trailing slash.
These tests verify the glob patch sent in a separate email.

regards, Dmitry

diff --git a/tests/run_make_tests.pl b/tests/run_make_tests.pl
index cd8a643..99d56bc 100644
--- a/tests/run_make_tests.pl
+++ b/tests/run_make_tests.pl
@@ -47,7 +47,7 @@ $all_tests = 0;
 $sh_name = '/bin/sh';
 $is_posix_sh = 1;
 
-$CMD_rmfile = 'rm -f';
+$CMD_rmfile = 'rm -rf';
 
 # rmdir broken in some Perls on VMS.
 if ($^O eq 'VMS')
diff --git a/tests/scripts/functions/wildcard b/tests/scripts/functions/wildcard
index f91d9ad..d1c0400 100644
--- a/tests/scripts/functions/wildcard
+++ b/tests/scripts/functions/wildcard
@@ -18,14 +18,30 @@ open(MAKEFILE,"> $makefile");
 # The Contents of the MAKEFILE ...
 
 print MAKEFILE <

[dgoncha...@users.sf.net: [PATCH] use own copy of glob.c]

[Dmitry Goncharov]

glibc's glob.c currently does not handle patterns with a trailing slash
correctly.
https://sourceware.org/bugzilla/show_bug.cgi?id=22513.

This patch switches to gmake's own implementaion of glob until glibc is fixed.
Once glibc is fixed a version check can be added.
If the tests patch submitted in another email is applied then this patch should
be applied as well. Otherwise, gmake won't pass the tests on glibc systems.

regards, Dmitry

diff --git a/configure.ac b/configure.ac
index 4710832..1e0c6f7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -410,7 +410,7 @@ AC_CACHE_CHECK([if system libc has GNU glob], 
[make_cv_sys_gnu_glob],
gnu glob
 # endif
 #endif],
-[make_cv_sys_gnu_glob=yes],
+[make_cv_sys_gnu_glob=no],
 [make_cv_sys_gnu_glob=no])])
 AS_IF([test "$make_cv_sys_gnu_glob" = no],
 [ GLOBINC='-I$(srcdir)/glob'
 
diff --git a/glob/glob.c b/glob/glob.c
index f3911bc..6f8c8a4 100644
--- a/glob/glob.c
+++ b/glob/glob.c
@@ -57,6 +57,7 @@ USA.  */
 # endif
 #endif
 
+#undef ELIDE_CODE
 #ifndef ELIDE_CODE
 
 #if defined STDC_HEADERS || defined __GNU_LIBRARY__
@@ -208,7 +209,7 @@ my_realloc (p, n)
 #endif /* __GNU_LIBRARY__ || __DJGPP__ */
 
 
-#if !defined __alloca && !defined __GNU_LIBRARY__
+#if !defined __alloca
 
 # ifdef__GNUC__
 #  undef alloca
@@ -255,6 +256,10 @@ extern char *alloca ();
 # endif
 #endif
 
+#ifndef __stat
+# define __stat stat
+#endif
+
 #if !(defined STDC_HEADERS || defined __GNU_LIBRARY__)
 # undefsize_t
 # define size_tunsigned int


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[PATCH] fix wildcard when pattern has a trailing slash.

[Dmitry Goncharov]

If patterns has a trailing slash then glob has to match directories only.

If the pattern is only 2 characters long (e.g. */) glob already matches
directories only. If the pattern is longer e.g. hello*/ then glob matches only
directories or files and directoires depending on type in readdir_result.

regards, Dmitry

diff --git a/glob/glob.c b/glob/glob.c
index f3911bc..6f8c8a4 100644
--- a/glob/glob.c
+++ b/glob/glob.c
@@ -370,6 +375,7 @@ glob (pattern, flags, errfunc, pglob)
   size_t dirlen;
   int status;
   int oldcount;
+  int retval = 0;
 
   if (pattern == NULL || pglob == NULL || (flags & ~__GLOB_FLAGS) != 0)
 {
@@ -1028,24 +1034,43 @@ glob (pattern, flags, errfunc, pglob)
   if (flags & GLOB_MARK)
 {
   /* Append slashes to directory names.  */
-  int i;
+  int i, e;
   struct stat st;
-  for (i = oldcount; i < pglob->gl_pathc; ++i)
-   if (((flags & GLOB_ALTDIRFUNC)
-? (*pglob->gl_stat) (pglob->gl_pathv[i], )
-: __stat (pglob->gl_pathv[i], )) == 0
-   && S_ISDIR (st.st_mode))
- {
-   size_t len = strlen (pglob->gl_pathv[i]) + 2;
-   char *new = realloc (pglob->gl_pathv[i], len);
-   if (new == NULL)
- {
-   globfree (pglob);
-   return GLOB_NOSPACE;
- }
-   strcpy ([len - 2], "/");
-   pglob->gl_pathv[i] = new;
- }
+  for (i = e = oldcount; i < pglob->gl_pathc + pglob->gl_offs; ++i)
+{
+ if (((flags & GLOB_ALTDIRFUNC)
+  ? (*pglob->gl_stat) (pglob->gl_pathv[i], )
+  : __stat (pglob->gl_pathv[i], )) == 0
+ && S_ISDIR (st.st_mode))
+   {
+ size_t len = strlen (pglob->gl_pathv[i]) + 2;
+ char *new = realloc (pglob->gl_pathv[i], len);
+ if (new == NULL)
+   {
+ globfree (pglob);
+ return GLOB_NOSPACE;
+   }
+ strcpy ([len - 2], "/");
+ if (pglob->gl_pathv[e] == NULL)
+   {
+ pglob->gl_pathv[e++] = new;
+ pglob->gl_pathv[i] = NULL;
+   }
+ else
+   pglob->gl_pathv[i] = new;
+   }
+ else if (flags & GLOB_ONLYDIR)
+   {
+ free (pglob->gl_pathv[i]);
+ pglob->gl_pathv[i] = NULL;
+ if (pglob->gl_pathv[e] != NULL)
+   e = i;
+   }
+   }
+   if (pglob->gl_pathv[e] == NULL)
+ pglob->gl_pathc = e - pglob->gl_offs;
+   if (pglob->gl_pathc == 0)
+ retval = GLOB_NOMATCH;
 }
 
   if (!(flags & GLOB_NOSORT))
@@ -1061,7 +1086,7 @@ glob (pattern, flags, errfunc, pglob)
 sizeof (char *), collated_compare);
 }
 
-  return 0;
+  return retval;
 }
 
 

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Handling posix_spawn for non-existent binaries

[Dmitry Goncharov]

On Wed, Jul 17, 2019 at 12:38 PM Paul Smith  wrote:
...
> The only idea I have so far is to try to detect when this situation
> occurs (by looking for the 127 exit status) then using stat() to check
> to see if the binary exists (I suppose I need to check for executable
> status) and generating the error on my own.

Subject to a race condition.

regads, Dmitry

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #57022] Error 127 executing a script with no #!

[Dmitry Goncharov]

Follow-up Comment #6, bug #57022 (project make):

Submitted a new test features/exec which reproduces this bug.

https://lists.gnu.org/archive/html/bug-make/2019-10/msg00046.html

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #57242] Non-recursive command passes invalid jobserver file descriptors

[Dmitry Goncharov]

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

Stefan, the behavior you described is intended.
make closes the pipe unless the command has + or (MAKE) or {MAKE}.
This is necessary, because a command can mess up job server operation or a
command may expect a specific fd to be available.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57022] Error 127 executing a script with no #!

[Dmitry Goncharov]

Follow-up Comment #4, bug #57022 (project make):

1. gmake posix_spawn's dodgy
2. fork inside posix_spawn succeeds and posix_spawn returns 0.
3. gmake skips fallback to /bin/sh because posix_spawn's return code is not
enoexec.
4. posix_spawn's child proceeds to exec dodgy and fails
5. posix_spawn does not have a fallback to /bin/sh and the child exits with
127.

The reason dodgy succeeds with SHELL=/bin/bash is gmake spawning /bin/bash and
passing as a parameter to /bin/bash via argv.
The reason dodgy fails with SHELL=/bin/sh is gmake treats SHELL=/bin/sh as if
no shell was explicitly specified in the makefile and again spawns dodgy.

Having configure disable posix_spawn was discussed here
https://lists.gnu.org/archive/html/bug-make/2019-09/msg0.html.

It is possible have gmake always spawn a shell (subject to configure test).
This solution'd cause gmake spawn a shell even when no shell is needed.

Paul, what about replacing --disable-posix-spawn with --enable-posix-spawn?

regards, Dmitry

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #57778] Stop looking for an included file once found, even if cannot be opened.

[Dmitry Goncharov]

URL:
  

 Summary: Stop looking for an included file once found, even
if cannot be opened.
 Project: make
Submitted by: dgoncharov
Submitted on: Sun 09 Feb 2020 05:07:07 PM UTC
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

Good morning. 
  
  
  
  
  
Stop looking for an included file once found, even if cannot be opened.   
  
  
  
  
  
If the current directory contains a not readable file and an additional
include directory contains a readable file the current file is silently
ignored and the file from the additional include directory is silently
included.
This can come as an unpleasant surprise and is hardly useful.
This behavior contradicts gnu make manual and usual practice in similar
situations.

Gnu make manual explicitly states that lookup continues only if the file is
missing.
Gnu make itself stops looking for a prerequisite file in vpath directories,
once it found one, even if cannot be opened.
Gnu make stops looking for an included file once it found one and the found
one turns out to be corrupt or a directory.
Similarly a compiler stops looking for a header once it found one, even if
cannot be opened.


The change from rmfiles to unlink in features/included is needed to have the
test pass when -keep is specified.

regards, Dmitry




___

File Attachments:


---
Date: Sun 09 Feb 2020 05:07:07 PM UTC  Name: stop_lookup_for_included.diff 
Size: 5KiB   By: dgoncharov



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57962] apparent regression involving PATH resolution

[Dmitry Goncharov]

Follow-up Comment #4, bug #57962 (project make):

The bug is in gnulib in function find_in_given_path.
This is a patch which fixes the bug.
The fix is likely needed for the windows specific piece of code in
find_in_given_path as well.

regards, Dmitry

diff --git a/lib/findprog-in.c b/lib/findprog-in.c
index c254f2f..d89ec00 100644
--- a/lib/findprog-in.c
+++ b/lib/findprog-in.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "filename.h"
 #include "concat-filename.h"
@@ -190,6 +191,7 @@ find_in_given_path (const char *progname, const char
*path,
   dir = ".";
 
 /* Try all platform-dependent suffixes.  */
+struct stat st;
 for (i = 0; i < sizeof (suffixes) / sizeof (suffixes[0]); i++)
   {
 const char *suffix = suffixes[i];
@@ -208,7 +210,8 @@ find_in_given_path (const char *progname, const char
*path,
use it.  On other systems, let's hope that this program
is not installed setuid or setgid, so that it is ok to
call access() despite its design flaw.  */
-if (eaccess (progpathname, X_OK) == 0)
+if (eaccess (progpathname, X_OK) == 0 &&
+stat(progpathname, ) == 0 && S_ISREG(st.st_mode))
   {
 /* Found!  */
 if (strcmp (progpathname, progname) == 0)







___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57962] apparent regression involving PATH resolution

[Dmitry Goncharov]

Follow-up Comment #3, bug #57962 (project make):

This is a test which reproduces the bug. The bug only manifests when
USE_POSIX_SPAWN is defined.

regards, Dmitry

diff --git a/tests/scripts/features/exec b/tests/scripts/features/exec
  
  
index 91181f4..3e6c3fa 100644 
  
  
--- a/tests/scripts/features/exec 
  
  
+++ b/tests/scripts/features/exec 
  
  
@@ -60,4 +60,20 @@ SHELL = #PERL# 
  
  
 all:; @printf "$(ANSWER)\n"; 
  
  
 !, "ANSWER='$answer'", "$answer\n"); 
  
  
  
  
  
+ 
  
  
+# test 16
  
  
+# Use sh as a shell, but create a directory called 'sh' in PATH. 
  
  
+# https://savannah.gnu.org/bugs/?57962.  
  
  
+mkdir("mybin", 0700);
  
  
+mkdir("mybin/sh", 0700); 
  
  
+run_make_test(q! 
  
  
+SHELL:=sh
  
  
+PATH:=mybin:$(PATH)  
  
  
+all:; @printf "$(ANSWER)\n"  
  
  
+!, "ANSWER='$answer'", "$answer\n"); 
  
  
+ 
  
  
+rmdir("mybin/sh");   
  
  
+rmdir("mybin");  
  
  
+ 
  
  
+ 
  
  
 1;



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57962] apparent regression involving PATH resolution

[Dmitry Goncharov]

Follow-up Comment #5, bug #57962 (project make):

i also submitted this patch to bug-gnulib mailing list.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57676] openjdk11 fails to build with make 4.3

[Dmitry Goncharov]

Follow-up Comment #10, bug #57676 (project make):

Here is a test for this.

+# Test 20.
+# When successfully read an included makefile, update its mtime, if needed.
+# https://savannah.gnu.org/bugs/?57676.
+
+unlink('hello.mk');
+run_make_test(q!
+-include hello.mk
+$(shell echo hello=world >hello.mk)
+include hello.mk
+default:; @echo $(hello)
+!,
+  '', "world\n");
+
+unlink('hello.mk');
+


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57676] openjdk11 fails to build with make 4.3

[Dmitry Goncharov]

Follow-up Comment #9, bug #57676 (project make):

make should not claim "cannot make the included makefile" having successfully
read the makefile.
Here is a patch which fixes the issue.

regards, Dmitry


diff --git a/src/makeint.h b/src/makeint.h
index c428a36..327849b 100644
--- a/src/makeint.h
+++ b/src/makeint.h
@@ -566,6 +566,8 @@ void print_dir_data_base (void);
 void dir_setup_glob (glob_t *);
 void hash_init_directories (void);
 
+FILE_TIMESTAMP name_mtime (const char *name);
+
 void define_default_variables (void);
 void undefine_default_variables (void);
 void set_default_suffixes (void);
diff --git a/src/read.c b/src/read.c
index db52a55..84e9f97 100644
--- a/src/read.c
+++ b/src/read.c
@@ -417,6 +417,10 @@ eval_makefile (const char *filename, unsigned short
flags)
 
   /* Success; clear errno.  */
   deps->error = 0;
+  /* Managed to read the file. Update mtime, if needed.
+ https://savannah.gnu.org/bugs/?57676.  */
+  if (deps->file->last_mtime == NONEXISTENT_MTIME)
+deps->file->last_mtime = name_mtime(deps->file->name);
 
   /* Avoid leaking the makefile to children.  */
   fd_noinherit (fileno (ebuf.fp));
diff --git a/src/remake.c b/src/remake.c
index fb237c5..956ca4c 100644
--- a/src/remake.c
+++ b/src/remake.c
@@ -67,7 +67,6 @@ static enum update_status check_dep (struct file *file,
unsigned int depth,
  FILE_TIMESTAMP this_mtime, int
*must_make);
 static enum update_status touch_file (struct file *file);
 static void remake_file (struct file *file);
-static FILE_TIMESTAMP name_mtime (const char *name);
 static const char *library_search (const char *lib, FILE_TIMESTAMP
*mtime_ptr);
 
 
@@ -1462,7 +1461,7 @@ f_mtime (struct file *file, int search)
This causes one duplicate stat() when -L is being used, but the code is
much cleaner.  */
 
-static FILE_TIMESTAMP
+FILE_TIMESTAMP
 name_mtime (const char *name)
 {
   FILE_TIMESTAMP mtime;


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #56301] Mandatory/Optional include files and pattern rule with multi-targets

[Dmitry Goncharov]

Follow-up Comment #3, bug #56301 (project make):

These patches are against the current master
(0c326a66c9eb3a3b5e4ab7892578b016b0590b1f).

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #55242] Included Makefile not found, no rule to build it but make does not fail

[Dmitry Goncharov]

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

Here is a patch against the current master
(0c326a66c9eb3a3b5e4ab7892578b016b0590b1f).

This patch causes make to re-execute itself to read the included makefile.

diff --git a/src/remake.c b/src/remake.c
index fb237c5..4dc91d8 100644
--- a/src/remake.c
+++ b/src/remake.c
@@ -175,24 +175,30 @@ update_goal_chain (struct goaldep *goaldeps)
 }
   else
 {
-  FILE_TIMESTAMP mtime = MTIME (file);
+  struct file *oldfile = file;
   check_renamed (file);
 
-  if (file->updated && g->changed &&
-   mtime != file->mtime_before_update)
+  if (file->updated && g->changed)
 {
-  /* Updating was done.  If this is a makefile and
- just_print_flag or question_flag is set
(meaning
- -n or -q was given and this file was specified
- as a command-line target), don't change STATUS.
- If STATUS is changed, we will get re-exec'd,
and
- enter an infinite loop.  */
-  if (!rebuilding_makefiles
-  || (!just_print_flag && !question_flag))
-status = us_success;
-  if (rebuilding_makefiles && file->dontcare)
-/* This is a default makefile; stop remaking. 
*/
-stop = 1;
+  FILE_TIMESTAMP lm = oldfile->last_mtime;
+  FILE_TIMESTAMP mtime =
+lm == UNKNOWN_MTIME || lm == NONEXISTENT_MTIME ?
+f_mtime (oldfile, 0) : lm;
+  if (mtime != file->mtime_before_update)
+{
+  /* Updating was done.  If this is a makefile
and
+ just_print_flag or question_flag is set
(meaning
+ -n or -q was given and this file was
specified
+ as a command-line target), don't change
STATUS.
+ If STATUS is changed, we will get re-exec'd,
and
+ enter an infinite loop.  */
+  if (!rebuilding_makefiles
+  || (!just_print_flag && !question_flag))
+status = us_success;
+  if (rebuilding_makefiles && file->dontcare)
+/* This is a default makefile; stop remaking.
 */
+stop = 1;
+}
 }
 }
 }


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #55242] Included Makefile not found, no rule to build it but make does not fail

[Dmitry Goncharov]

Follow-up Comment #2, bug #55242 (project make):

Here is a test.

diff --git a/tests/scripts/features/include b/tests/scripts/features/include
index 0c63c06..f39e5ec 100644
--- a/tests/scripts/features/include
+++ b/tests/scripts/features/include
@@ -260,4 +260,16 @@ inc1:; @%s $@ && echo FOO := bar > $@
 rmfiles('inc1');
 }
 
+unlink('b');
+unlink('a.mk');
+run_make_test(q!
+all:; @echo hello=$(hello)
+include a.mk
+a.mk: b
+b:
+   @echo hello=world >a.mk
+!, '', 'hello=world');
+unlink('a.mk');
+unlink('b');
+
 1;


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #56301] Mandatory/Optional include files and pattern rule with multi-targets

[Dmitry Goncharov]

Follow-up Comment #4, bug #56301 (project make):

This test is the same as the one submitted earlier, but unlinks the included
makefiles.

diff --git a/tests/scripts/features/include b/tests/scripts/features/include
index 0c63c06..4401622 100644
--- a/tests/scripts/features/include
+++ b/tests/scripts/features/include
@@ -260,4 +260,15 @@ inc1:; @%s $@ && echo FOO := bar > $@
 rmfiles('inc1');
 }
 
+# Stop when cannot include a makefile.
+# https://savannah.gnu.org/bugs/?56301.
+unlink('inc_a.mk');
+unlink('inc_b.mk');
+run_make_test(q!
+all:; @echo hello
+include inc_a.mk
+-include inc_b.mk
+%_a.mk %_b.mk:; @false
+!, '', "#MAKE#: Failed to remake makefile 'inc_a.mk'.", 512);
+
 1;


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #55242] Included Makefile not found, no rule to build it but make does not fail

[Dmitry Goncharov]

Additional Item Attachment, bug #55242 (project make):

File name: sv_55242_let_included_files_be_byproduct_of_unrelated_rules.diff
Size:2 KB
   


File name:
sv_55242_let_included_files_be_byproduct_of_unrelated_rules_test.diff Size:0
KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #56301] Mandatory/Optional include files and pattern rule with multi-targets

[Dmitry Goncharov]

Follow-up Comment #2, bug #56301 (project make):

Here is a test.
diff --git a/tests/scripts/features/include b/tests/scripts/features/include
index 0c63c06..2281ee4 100644
--- a/tests/scripts/features/include
+++ b/tests/scripts/features/include
@@ -260,4 +260,13 @@ inc1:; @%s $@ && echo FOO := bar > $@
 rmfiles('inc1');
 }
 
+# Stop when cannot include a makefile.
+# https://savannah.gnu.org/bugs/?56301.
+run_make_test(q!
+all:; @echo hello
+include inc_a.mk
+-include inc_b.mk
+%_a.mk %_b.mk:; @false
+!, '', "#MAKE#: Failed to remake makefile 'inc_a.mk'.", 512);
+
 1;


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #56301] Mandatory/Optional include files and pattern rule with multi-targets

[Dmitry Goncharov]

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

Here is a fix.

diff --git a/src/main.c b/src/main.c
index bcba2d1..5c1a7da 100644
--- a/src/main.c
+++ b/src/main.c
@@ -2305,6 +2305,8 @@ main (int argc, char **argv, char **envp)
 any_remade |= (mtime != NONEXISTENT_MTIME
&& mtime != makefile_mtimes[i]);
 makefile_status = MAKE_FAILURE;
+if (!keep_going_flag)
+  any_failed = 1;
   }
   }
 else


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58056] Forced prerequisite order is not honored with pattern rules

[Dmitry Goncharov]

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

This behavior is intended.

1. To figure out if a target has to be rebuilt make traverses the list of
prerequisites and finds out if any of the prerequisites, but not intermediate
prerequisites, need to be rebuilt.
During this traverse make rebuilds all prerequisites that are out of date. If,
during this traverse, make finds out that some prerequisite was out of date,
then make proceeds to rebuild intermediate prerequisites.

Intermediate prerequisites are not rebuild during this traverse along with
prerequisites because, if all prerequisites are up to date then the target is
up to date and there is no need to built intermediate prerequisites.

In your example
foo_A is an intermediary prerequisite.
foo_B is a prerequisite.

2. Another reason is to allow parallel execution. If all prerequisites had to
be built in the specified order how would you built them in parallel?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58365] make 4.3 segfault on s390x alpine linux

[Dmitry Goncharov]

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

Can you please attach a makefile which reproduces the crash?

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #58013] .SILENT appears to be ignored in GNU Make 4.3

[Dmitry Goncharov]

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

This is intentional.
See https://savannah.gnu.org/bugs/?54740.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58013] .SILENT no longer suppresses "Entering directory"

[Dmitry Goncharov]

Follow-up Comment #7, bug #58013 (project make):

Posix is explicit that -s and .SILENT are both about command lines.
If we wanted to be strictly posix conformant 'Entering directory' should be
printed even when -s is specified.
if .SILENT is stretched to suppress other messages such as 'Entering
directory' the question arises which other messages should .SILENT suppress?
e.g. if the directory is not executable make prints "permission denied".
Should "permission denied" be suppressed? What about $(warning ) messages, "is
up to date" messages, etc?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58013] .SILENT no longer suppresses "Entering directory"

[Dmitry Goncharov]

Follow-up Comment #4, bug #58013 (project make):

"Entering directory' message when the user is not expecting one is a benign
backward incompatibility. i'd be more concern about the opposite.
Also, reinstating the prior behavior is incompatible with 4.3.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58435] make 4.3 is not c89 compliant

[Dmitry Goncharov]

Follow-up Comment #2, bug #58435 (project make):

This code was introduced when a local implementation of strerror was replaced
with gnulib's one.

commit 4d00ceba264a9fd04241dcd2685526ce64c1346b
Author: Paul Smith 
Date:   Sat Jul 13 08:34:45 2019 -0400

Switch to the gnulib version of strerror()

* bootstrap.conf: Add strerror module
* configure.ac: Remove strerror check
* src/misc.c: Remove local strerror() implementation
* src/config.ami.template: Remove HAVE_STRERROR
* src/config.h-vms.template: Ditto.
* src/config.h.W32.template: Ditto.


Either c90 conformance has to be dropped or code from gnulib cannot be easily
integrated.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59096] The built in rule for archives fails on aix.

[Dmitry Goncharov]

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

This is a patch which fixes this rule.

diff --git a/src/default.c b/src/default.c
index 751ea15..7d31355 100644
--- a/src/default.c
+++ b/src/default.c
@@ -71,6 +71,9 @@ static struct pspec default_pattern_rules[] =

 #else
 { "(%)", "%",
+#ifdef _AIX
+"OBJECT_MODE=any "
+#endif
 "$(AR) $(ARFLAGS) $@ $<" },
 #endif
 /* The X.out rules are only in BSD's default set because


___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #59096] The built in rule for archives fails on aix.

[Dmitry Goncharov]

URL:
  

 Summary: The built in rule for archives fails on aix.
 Project: make
Submitted by: dgoncharov
Submitted on: Чт 10 сен 2020 23:40:31
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

$ cat makefile
all: libhello.a(a.o)
%.o: %.c
$(CC) -c -maix64 $<
a.c:
echo 'static int a;' >$@
$
$ make
gcc -c -maix64 a.c
ar rv libhello.a a.o
ar: Creating an archive file libhello.a.
a - a.o
ar: 0707-126 a.o is not valid with the current object file mode.
Use the -X option to specify the desired object mode.
: recipe for target 'libhello.a(a.o)' failed
make: *** [libhello.a(a.o)] Error 1
rm a.o
$

Aix ar requires an option to specify the object file format.

Quote from
https://www.ibm.com/support/knowledgecenter/ssw_aix_72/a_commands/ar.html


"-X modeSpecifies the type of object file ar should examine. The mode 
must be
one of the following:
32
Processes only 32-bit object files
64
Processes only 64-bit object files
32_64
Processes both 32-bit and 64-bit object files
d64
Examines discontinued 64-bit XCOFF files (magic number == U803XTOCMAGIC).
any
Processes all of the supported object files.
The default is to process 32-bit object files (ignore 64-bit objects). The
mode can also be set with the OBJECT_MODE environment variable. For example,
OBJECT_MODE=64 causes ar to process any 64-bit objects and ignore 32-bit
objects. The -X flag overrides the OBJECT_MODE variable."






___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #59093] Segmentation fault regression in make 4.3 vs. 4.2.1

[Dmitry Goncharov]

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

This is caused by stack overflow.
A change introduced in commit 4f3a41c60a02f6df9fc0725698ade64825907822
prevents setting stack size if posix_spawn is used.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59093] Segmentation fault regression in make 4.3 vs. 4.2.1

[Dmitry Goncharov]

Additional Item Attachment, bug #59093 (project make):

File name: sv59093_set_stack_size.diffSize:0 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59093] Segmentation fault regression in make 4.3 vs. 4.2.1

[Dmitry Goncharov]

Follow-up Comment #2, bug #59093 (project make):

This patch in the attachment solves the issue.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59247] function shell eats a newline

[Dmitry Goncharov]

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

The patch in the attachment fixes the issue.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59247] function shell eats a newline

[Dmitry Goncharov]

Additional Item Attachment, bug #59247 (project make):

File name: sv_59247_func_shell_eats_newline.diff Size:1 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59247] function shell eats a newline

[Dmitry Goncharov]

URL:
  

 Summary: function shell eats a newline
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 10 Oct 2020 06:24:33 PM UTC
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

A user reported a bug here

https://lists.gnu.org/archive/html/bug-make/2020-10/msg00016.html.

From:   Byrnes, Robert
Subject:embedded newlines in shell function variable expansion
Date:   Fri, 9 Oct 2020 15:03:24 +

If I use this Makefile ...


bash$ cat Makefile
FOO := $(shell echo $(ENTRIES) ; )
BAR := $(shell echo $(ENTRIES)   )

all:
@echo FOO = $(FOO)
@echo BAR = $(BAR)

.PHONY: all


... and set ENTRIES with embedded newlines, then this happens:


bash$ make 'ENTRIES=
blartz
blurfl
'
FOO = blartzblurfl
BAR = blartz blurfl





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59230] Conditional assigment of a target specific variable prevents export

[Dmitry Goncharov]

URL:
  

 Summary: Conditional assigment of a target specific variable
prevents export
 Project: make
Submitted by: dgoncharov
Submitted on: Tue 06 Oct 2020 10:38:50 PM UTC
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

I user reported a bug here

https://lists.gnu.org/archive/html/bug-make/2020-10/msg1.html


Hi,

I just got a build failure in lz4.  I've isolated it and made a minimal test 
case, see below.

This is on GNU Guix on a x86_64 machine.

The reason is that apparently one Makefile rule can unwittingly change how 
another unrelated rule functions, IF a submake is involved.

To reproduce:

$ cat Makefile 

all:
$(MAKE) -C foo all

dummy: CFLAGS ?= bar
dummy:

$ cat foo/Makefile 

CFLAGS ?= internal

all:
echo $(CFLAGS)

Expected behavior:

$ CFLAGS=ok make
make -C foo all
make[1]: Entering directory 'foo'
echo ok
ok
make[1]: Leaving directory 'foo'

Actual behavior:

$ CFLAGS=ok make
make -C foo all
make[1]: Entering directory 'foo'
echo internal
internal
make[1]: Leaving directory 'foo'

BR,
   Danny Milosavljevic




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59230] Conditional assigment of a target specific variable prevents export

[Dmitry Goncharov]

Follow-up Comment #3, bug #59230 (project make):

That is assignment of a global variable prevents export of a target specific
variable.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59230] Conditional assigment of a target specific variable prevents export

[Dmitry Goncharov]

Follow-up Comment #4, bug #59230 (project make):

The second patch fixes this second issue.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59230] Conditional assigment of a target specific variable prevents export

[Dmitry Goncharov]

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

The attached patch fixes the issue.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59230] Conditional assigment of a target specific variable prevents export

[Dmitry Goncharov]

Additional Item Attachment, bug #59230 (project make):

File name:
sv59230_assignment_of_a_global_variable_prevents_export_of_a_target_specific_variable.diff
Size:1 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59230] Conditional assigment of a target specific variable prevents export

[Dmitry Goncharov]

Follow-up Comment #2, bug #59230 (project make):

However, the following example still fails, even with the attached patch
applied.

$ cat makefile
all:; @echo hello=$$hello
hello=sun
dummy: hello?=world

$ hello=moon  make
hello=



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59230] Conditional assigment of a target specific variable prevents export

[Dmitry Goncharov]

Additional Item Attachment, bug #59230 (project make):

File name: sv59230_conditional_assignment_of_a_target_var Size:1 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58979] Recursive make using jobserver hangs at completion

[Dmitry Goncharov]

Follow-up Comment #10, bug #58979 (project make):

> No. It did not hang.

-n causes make to run only recursive commands. And the hang does not reproduce
with -n. Which makes us suspect all the other (not recursive) commands.

There are atleast the following debugging options.

Remove recipies one by one until the hang is gone.

or

1. Add logging to jobserver_setup to print the pipe fd.
2. Add a sleep in makefile at the very beginning to give you time to run
auditctl.
3. Run make and see which fds are allocated for the pipe.
4. Run auditctl to see all processes which open your pipe, write to your pipe,
read from your pipe.

or

1. Add logging to jobserver_setup to print the pipe fd.
2. Add a sleep in makefile at the very beginning.
3. Run make and see which pid it has.
4. See in /proc//fd/ the pipe id. It'll look like
$ ls -l /proc/92678/fd/5
lr-x-- 1 dgoncharov who 64 Aug 25 17:46 /proc/92678/fd/5 ->
pipe:[97436149]. Notice pipe id. In this case 97436149.
5. Run lsof |grep  repeately in a loop and redirect the output to a
file. It'll look like
$ lsof |grep -- '97436149 pipe'
make   92678 dgoncharov5r FIFO0,8   0t0
97436149 pipe
sleep  92679 dgoncharov1w FIFO0,8   0t0
97436149 pipe
sleep  92679 dgoncharov5r FIFO0,8   0t0
97436149 pipe

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #58979] Recursive make using jobserver hangs at completion

[Dmitry Goncharov]

Follow-up Comment #11, bug #58979 (project make):

> but I have never put '+' on any recipes.  When is that needed?

'+' cause make to keep the jobserver pipe fd open on exec of that command and
also run the command regardless of -n, -p, -q.

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #58979] Recursive make using jobserver hangs at completion

[Dmitry Goncharov]

Follow-up Comment #3, bug #58979 (project make):

David, can you please attach the makefiles which reproduce the issue?

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #58979] Recursive make using jobserver hangs at completion

[Dmitry Goncharov]

Follow-up Comment #8, bug #58979 (project make):

> I've attached my makefiles.

i guess, a clarification is needed.

The attached makefiles are a part of a bigger system. The other part is
missing. It is not possible to reproduce the issue with the attached makefiles
for anyone who is missing the other part.

Can you write the smallest possible makefile (or a set of makefiles), such
that even people who don't have your full build environment can run to
reproduce the issue?


> Per your suggestion, I ran with '-n.'  It revealed nothing interesting. 

Did it hang or not?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58961] Document dynamic phony targets.

[Dmitry Goncharov]

Additional Item Attachment, bug #58961 (project make):

File name: doc_dynamic_phony_targets.diff Size:1 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58961] Document dynamic phony targets.

[Dmitry Goncharov]

URL:
  

 Summary: Document dynamic phony targets.
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 15 Aug 2020 02:44:41 PM UTC
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

Document dynamic phony targets.

diff --git a/doc/make.texi b/doc/make.texi
index 21573c0..a8aa3a2 100644
--- a/doc/make.texi
+++ b/doc/make.texi
@@ -2829,6 +2829,28 @@ cleandiff :
 rm *.diff
 @end example
 
+.PHONY works with prerequisites statically defined in the makefile.
+Declaring a target that changes depending on user input or some other
external
+condition as a prerequisites of .PHONY will not achieve the desired effect.
+
+@example
+print-%:
+   @@echo $* = $($*)
+@end example
+
+This rule will print the value of a variable specified by the user on the
+command line.
+
+If you say @samp{make print-OBJ}, make will print the value of variable
@var{obj}.
+However, if there is a file called print-OBJ in the current directory, then
this
+rule will not be executed.
+
+Declaring @samp{print-%} a prerequisite of .PHONY will not work, because
when
+you say @samp{make print-OBJ} the target is @samp{print-OBJ}, not
+@samp{print-%}.
+
+You can force such target. @xref{Force Targets}.
+
 @node Force Targets, Empty Targets, Phony Targets, Rules
 @section Rules without Recipes or Prerequisites
 @cindex force targets




___

File Attachments:


---
Date: Sat 15 Aug 2020 02:44:41 PM UTC  Name: doc_dynamic_phony_targets.diff 
Size: 1KiB   By: dgoncharov



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58960] Fix a typo in the manual

[Dmitry Goncharov]

URL:
  

 Summary: Fix a typo in the manual
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 15 Aug 2020 02:42:53 PM UTC
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

Fix a typo in the manual.

diff --git a/doc/make.texi b/doc/make.texi
index 21573c0..cc35c59 100644
--- a/doc/make.texi
+++ b/doc/make.texi
@@ -11795,7 +11795,7 @@ control characters are not emitted so that they don't
corrupt log
 files, etc.
 
 The @code{--output-sync} (@pxref{Parallel Output, ,Output During
-Parallel Output}) option will defeat the terminal detection.  When
+Parallel Execution}) option will defeat the terminal detection.  When
 output synchronization is enabled GNU @code{make} arranges for all
 command output to be written to a file, so that its output can be
 written as a block without interference from other commands.  This




___

File Attachments:


---
Date: Sat 15 Aug 2020 02:42:53 PM UTC  Name: doc_sync_out_typo.diff  Size:
626B   By: dgoncharov



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58961] Document dynamic phony targets.

[Dmitry Goncharov]

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

Please use the latest attached file.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59093] Segmentation fault regression in make 4.3 vs. 4.2.1

[Dmitry Goncharov]

Additional Item Attachment, bug #59093 (project make):

File name: defss.diff Size:2 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59093] Segmentation fault regression in make 4.3 vs. 4.2.1

[Dmitry Goncharov]

Follow-up Comment #5, bug #59093 (project make):

The only issue i encountered with make children inheriting a high value of
RLIMIT_STACK was a 32 bit compiler running out of heap when compiling a large
file.

i attached another patch.
This patch sets stack limit to a default hardcoded value when posix_spawn is
enabled. The default is 128Mb. This deprives a 32 bit compiler of 128 Mb out
of its ~2Gb of space.

For those (if any) makefiles which need more than 128Mb of stack we can
introduce 2 new make functions "setrlimit" and "getrlimit". The makefile could
then call "setrlimit". This will relieve the users from the crash and from
having to know the reason of the crash.
Paul, if you think we should add "setrlimit" and "getrlimit" functions please
let me know, i'll submit a patch.


> If the user invokes make and the stack size they specify is too small then
maybe they should increase the stack size before invoking make (they can do
this with ulimit -s before invoking make).

The user won't know what causes the crash.


> Alternatively, maybe it's possible for make to dynamically reset the stack
limit before invoking posix_spawn().

make would have to know the amount of stack occupied to set this smaller
limit.
Also, what to do is this occupied amount is large?


> I don't see any good way to avoid function calls being recursive 

Another option is to keep recursion, but rewrite the code to allow tail call
optimization.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58734] gmake does not check for the existence of a file before complaining it is missing

[Dmitry Goncharov]

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

Can you please attach a makefile that demonstrates the issue?

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #58639] Shortest stem not matched

[Dmitry Goncharov]

Follow-up Comment #2, bug #58639 (project make):

Paul, do you think we can describe this scenario this explicitly in the doc?
E.g.

diff --git a/doc/make.texi b/doc/make.texi
index 733c0b9..9c625d7 100644
--- a/doc/make.texi
+++ b/doc/make.texi
@@ -10342,9 +10342,9 @@ A pattern rule can be used to build a given file only
if there is a
 target pattern that matches the file name, @emph{and} all
 prerequisites in that rule either exist or can be built.  The rules
 you write take precedence over those that are built in. Note however,
-that a rule whose prerequisites actually exist or are mentioned always
-takes priority over a rule with prerequisites that must be made by
-chaining other implicit rules.
+that a rule whose prerequisites actually exist or are mentioned or
+which has no prerequisites always takes priority over a rule with
+prerequisites that must be made by chaining other implicit rules.
 
 @cindex stem, shortest
 It is possible that more than one pattern rule will meet these


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58529] MAKEOVERRIDES does not change the origin

[Dmitry Goncharov]

Follow-up Comment #2, bug #58529 (project make):

make manual specifies that the only thing legal to do with MAKEOVERRIDES is to
reset it.
Why do you want to set new contents of MAKEOVERRIDES? MAKEOVERRIDES is not
intended for this use.
You can override a variable using override.
override FOO=z


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58497] inconsistent newline removal in $(file <)

[Dmitry Goncharov]

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

Attached another fix along with new tests.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58497] inconsistent newline removal in $(file <)

[Dmitry Goncharov]

Additional Item Attachment, bug #58497 (project make):

File name: sv_58497_fix_function_file.diff Size:0 KB
   


File name: sv_58497_fix_function_file_tests.diff Size:2 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58497] inconsistent newline removal in $(file <)

[Dmitry Goncharov]

Follow-up Comment #2, bug #58497 (project make):

However, i'd like to be able to reproduce realloc returning a smaller
address.
Ken, do you have a makefile which reproduces this?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59601] buffer over-read on malformed environment variable

[Dmitry Goncharov]

Follow-up Comment #2, bug #59601 (project make):

Thanks for your report. Here is a patch.

diff --git a/src/main.c b/src/main.c
index 9066513..64e2529 100644
--- a/src/main.c
+++ b/src/main.c
@@ -1364,7 +1364,7 @@ main (int argc, char **argv, char **envp)
 enum variable_export export = v_export;
 size_t len;
 
-while (! STOP_SET (*ep, MAP_EQUALS))
+while (! STOP_SET (*ep, MAP_EQUALS|MAP_NUL))
   ++ep;
 
 /* If there's no equals sign it's a malformed environment.  Ignore. 
*/


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59762] make --touch produce local spurious empty files with out-of-tree Makefile strategy

[Dmitry Goncharov]

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

You target.mk contains rule

% :: $(DIR_TARGET) ; :

When you run
$ make file1.o

make finds this rule, with % being file1.o and its prerequisite being build.
Make then makes this prerequisite and then proceeds to execute the recipe to
make file1.o from this prerequisite. In this rule this recipe is :.

See that : printed after linking pgm.x?

When you run

$ make -t file1.o
make finds this rule, with % being file1.o and its prerequisite being build.
Make then makes this prerequisite (this is the first touch which creates
file1.o in the build directory) and then proceeds to make file1.o. Because -t
is specified  make touches file1.o in the parent directory.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59490] target may not be remade if prerequisite has no recipe

[Dmitry Goncharov]

Follow-up Comment #2, bug #59490 (project make):

Greg, you observe the effect of make fs cache.
In order to avoid this effect you need to tell make explicitly that c1 is to
be rebuilt when b1 changes.

e.g.

b1: a1
touch b1
c1: b1
touch c1
d1: c1
touch d1


___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #59881] Segmentation Fault through manipulated Makefile

[Dmitry Goncharov]

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

This makefile causes variable_buffer_output to realloc. This renders buffer in
enter_prereqs invalid.

Here is a patch.

diff --git a/src/file.c b/src/file.c
index a979ca5..61f0a56 100644
--- a/src/file.c
+++ b/src/file.c
@@ -524,8 +524,12 @@ enter_prereqs (struct dep *deps, const char *stem)
   continue;
 }

-  /* Save the name.  */
-  dp->name = strcache_add_len (buffer, o - buffer);
+  /* Save the name.
+   * VARIABLE_BUFFER_OUTPUT could realloc, which'd render BUFFER
+   * invalid.
+   * sv 59881.  */
+  dp->name = strcache_add_len (variable_buffer,
+   o - variable_buffer);
 }
   dp->stem = stem;
   dp->staticpattern = 1;


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59881] Segmentation Fault through manipulated Makefile

[Dmitry Goncharov]

Follow-up Comment #3, bug #59881 (project make):

Thank you for your report.
How did you manage to obtain this makefile?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59881] Segmentation Fault through manipulated Makefile

[Dmitry Goncharov]

Follow-up Comment #2, bug #59881 (project make):

Here is a test.

diff --git a/tests/scripts/functions/error b/tests/scripts/functions/error
index 998afe4..cb8fcc4 100644
--- a/tests/scripts/functions/error
+++ b/tests/scripts/functions/error
@@ -63,6 +63,28 @@ $answer = "Some stuff\n$makefile:17: *** error is
definitely.  Stop.\n";
 $answer = "$makefile:22: *** Error found!.  Stop.\n";
 _output($answer,_logfile(1));
 
+
+# Test #6
+# A makefile which causes variable_buffer_output to realloc and renders
buffer
+# invalid and used to crash make.
+# sv 59881.
+my $makestring = ':
+
+0:
+
+000

0:
+0%0:%0
+0';
+
+open(MAKEFILE, "> $makefile") or die "Failed to open $makefile: $!\n";
+print MAKEFILE $makestring;
+close(MAKEFILE) or die "Failed to write $makefile: $!\n";
+
+_make_with_options($makefile, '', _logfile, 512);
+my $answer = "$makefile:4: *** missing separator.  Stop.\n";
+_output($answer, _logfile(1));
+
+
 # This tells the test driver that the perl test script executed properly.
 1;


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59870] Segmentation Fault on GNU

[Dmitry Goncharov]

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

Here is a patch.
i am not adding a test, because there is a commented out test 19 in
targetvars, which expects different behavior.
Thank you for your report and the test case.


diff --git a/src/read.c b/src/read.c
index 545514c..11ef748 100644
--- a/src/read.c
+++ b/src/read.c
@@ -1802,10 +1802,11 @@ record_target_var (struct nameseq *filenames, char
*defn,
   /* Get a reference for this pattern-specific variable struct.  */
   p = create_pattern_var (name, percent);
   p->variable.fileinfo = *flocp;
-  /* I don't think this can fail since we already determined it was
a
- variable definition.  */
+  /* Could be a variable definition or %:define or %:undefine.
+ sv 59870.  */
   v = assign_variable_definition (>variable, defn);
-  assert (v != 0);
+  if (!v)
+O (fatal, flocp, _("Malformed pattern-specific variable
definition"));
 
   v->origin = origin;
   if (v->flavor == f_simple)


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59956] Recipes inside conditionals can break the parser

[Dmitry Goncharov]

Follow-up Comment #6, bug #59956 (project make):

What about adding another keyword, e.g. .else?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60777] Command line switch --trace disables -d.

[Dmitry Goncharov]

Additional Item Attachment, bug #60777 (project make):

File name: sv_60777_fix.diff  Size:0 KB


File name: sv_60777_test.diff Size:0 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60777] Command line switch --trace disables -d.

[Dmitry Goncharov]

URL:
  

 Summary: Command line switch --trace disables -d.
 Project: make
Submitted by: dgoncharov
Submitted on: Sun 13 Jun 2021 09:16:10 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:


Commit 7044e0c93 introduced a change which breaks -d when --trace is
specified.

$ cat makefile 
all: ; :
$ ~/src/gmake/make/l64/make -rd --trace
makefile:1: update target 'all' due to: target does not exist
:
$

There is no -d output.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60799] Parser chokes on second expansion of a prerequisite with ; o #

[Dmitry Goncharov]

URL:
  

 Summary: Parser chokes on second expansion of a prerequisite
with ; o #
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 19 Jun 2021 01:41:58 PM UTC
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

Parser chokes on second expansion of a prerequisite with ; o #

$ cat makefile 
MAKEFLAGS+=--warn-undefined-variables
.SECONDEXPANSION:
hello: $$(shell echo world;)
touch $@

bye: $$(hello#world)
touch $@
$ make hello
makefile:7: *** unterminated variable reference.  Stop.
$ make bye
makefile:7: *** unterminated variable reference.  Stop.
$ 


Parser treats ; as a recipe delimiter and # as a comment delimiter.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60799] Parser chokes on second expansion of a prerequisite with ; o #

[Dmitry Goncharov]

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


[comment #0 original submission:]
> Parser chokes on second expansion of a prerequisite with ; o #
> 
> $ cat makefile 
> MAKEFLAGS+=--warn-undefined-variables
> .SECONDEXPANSION:
> hello: $$(shell echo world;)
> touch $@
> 
> bye: $$(hello#world)
> touch $@
> $ make hello
> makefile:7: *** unterminated variable reference.  Stop.
> $ make bye
> makefile:7: *** unterminated variable reference.  Stop.
> $ 
> 
> 
> Parser treats ; as a recipe delimiter and # as a comment delimiter.

(file #51584, file #51585)
___

Additional Item Attachment:

File name: sv_60799_se_semi_fix.diff  Size:4 KB
   


File name: sv_60799_se_semi_test.diff Size:3 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60799] Parser chokes on second expansion of a prerequisite with ; o #

[Dmitry Goncharov]

Follow-up Comment #3, bug #60799 (project make):

Yes, it is possible to store special characters in a variable.

i'd not bother fixing this, if not for the fact that make already supports
this input. It is just when second expansion is enabled the parser fails.

i don't think this inconsistency can be described in the manual.

This works fine
hello: $(shell echo world;)

This does not work
.SECONDEXPANSION:
hello: $$(shell echo world;)

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60811] Add long-form aliases for automatic variables

[Dmitry Goncharov]

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

$<, $@, etc are the portable automatic variables. These are standardized by
posix and supported by other unix makes, e.g. sun and ibm makes.
On the other hand, .IMPSRC, etc are not portable.
Introduction of .IMPSRC to gmake cannot improve portability, it can only
hinder it.
Have you considered adding $<, etc to bsd make to improve portability?

In regards to readability, i like this

%.o: %.c
cc -o $@ -c $<

much better than this

%.o: %.c
cc -o $(.TARGET) -c $(.IMPSRC)


___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #60077] Deterministic $@ for grouped targets patch

[Dmitry Goncharov]

Follow-up Comment #5, bug #60077 (project make):

Todd, thank for your contribution.

Your patch is missing second expansion tests.

i observe the following misbehavior.


$ cat makefile
.SECONDEXPANSION:

hello world&: $$(info in prereqs @ = $$@, @< = $$(@<), @^ = $$(@^))
$(info in recipe @ = $@, @< = $(@<), @^ = $(@^))
$ ~/src/gmake/make/l64/make -f makefile hello
in prereqs @ = world, @< = hello, @^ = hello world
in prereqs @ = hello, @< = hello, @^ = hello world
in recipe @ = hello, @< = hello, @^ = hello world
make: 'hello' is up to date.
$
$
$ cat makefile4
.SECONDEXPANSION:

all: world.z hello.x

%.x %.z&: $$(info in prereqs @ = $$@, @< = $$(@<), @^ = $$(@^))
$(info in recipe @ = $@, @< = $(@<), @^ = $(@^))
$ ~/src/gmake/make/l64/make -f makefile4 hello.x
in prereqs @ = hello.x, @< = hello.x, @^ = hello.x
in recipe @ = hello.x, @< = hello.x, @^ = hello.x hello.z
make: 'hello.x' is up to date.


Explicit rules are good.
However, you can see during the 2nd expansion of implicit rules @^ expands to
the 1st target, rather than the whole group.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60595] make doesn't always restart when a makefile is rebuilt

[Dmitry Goncharov]

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

Can you please attach a makefile which reproduces the issue?

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #60659] Incorrect 2nd expansion of $$< inside a function in the prerequisite list.

[Dmitry Goncharov]

Additional Item Attachment, bug #60659 (project make):

File name: sv60659_fix.diff   Size:0 KB


File name: sv60659_test_implicit.diff Size:3 KB
   


File name: sv60659_test_explicit.diff Size:2 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60659] Incorrect 2nd expansion of $$< inside a function in the prerequisite list.

[Dmitry Goncharov]

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

Attached tests of explicit and implicit rules and a fix.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60659] Incorrect 2nd expansion of $$< inside a function in the prerequisite list.

[Dmitry Goncharov]

URL:
  

 Summary: Incorrect 2nd expansion of $$< inside a function in
the prerequisite list.
 Project: make
Submitted by: dgoncharov
Submitted on: Sun 23 May 2021 02:26:36 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

.SECONDEXPANSION:
hello.x: world.z
hello.x: $$(info <=$$<) ;

Expected output of info is
<=world.z

Actual output of info is
<=

$(info) is used in this example. Other functions cause the same effect.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60699] Avoid calling strlen repeatedly in a loop.

[Dmitry Goncharov]

Additional Item Attachment, bug #60699 (project make):

File name: sv60699_fix.diff   Size:1 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60699] Avoid calling strlen repeatedly in a loop.

[Dmitry Goncharov]

Follow-up Comment #2, bug #60699 (project make):

Sure, here is a unified diff.

Rather than attaching diffs, we could submit git branches for review. What do
you think?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60659] Incorrect 2nd expansion of $$< inside a function in the prerequisite list.

[Dmitry Goncharov]

Follow-up Comment #3, bug #60659 (project make):

Sure, will do.
Thanks for review.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60699] Avoid calling strlen repeatedly in a loop.

[Dmitry Goncharov]

URL:
  

 Summary: Avoid calling strlen repeatedly in a loop.
 Project: make
Submitted by: dgoncharov
Submitted on: Sun 30 May 2021 12:08:15 AM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

Avoid calling strlen repeatedly in a loop in initialize_file_variables.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60699] Avoid calling strlen repeatedly in a loop.

[Dmitry Goncharov]

Additional Item Attachment, bug #60699 (project make):

File name: sv60699_fix.diff   Size:0 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60736] Introduce "Circular <- dependency dropped." for .EXTRA_PREREQS deps.

[Dmitry Goncharov]

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

With the patch in the attachment the output is

$ make -f makefile2 
make: Circular hello.x <- hello.x dependency dropped.
touch hello.x
$

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60736] Introduce "Circular <- dependency dropped." for .EXTRA_PREREQS deps.

[Dmitry Goncharov]

Additional Item Attachment, bug #60736 (project make):

File name: sv_60736_add_avoid_circular_dep_msg.diff Size:0 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60736] Introduce "Circular <- dependency dropped." for .EXTRA_PREREQS deps.

[Dmitry Goncharov]

URL:
  

 Summary: Introduce "Circular  <-  dependency
dropped." for .EXTRA_PREREQS deps.
 Project: make
Submitted by: dgoncharov
Submitted on: Sun 06 Jun 2021 01:33:46 AM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

Introduce "Circular  <-  dependency dropped." for .EXTRA_PREREQS
dependencies.


$ cat makefile2
hello.x: ; touch $@
hello.x: .EXTRA_PREREQS:=hello.x
$ make -f makefile2
touch hello.x
$

"make: Circular hello.x <- hello.x dependency dropped." is missing.

The message is useful and make prints it in the case of a regular (as opposite
to .EXTRA_PREREQS) circular dependency.





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60904] More accurate description of intermediate files

[Dmitry Goncharov]

URL:
  

 Summary: More accurate description of intermediate files
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 10 Jul 2021 02:53:15 PM UTC
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

The manual states

"The first difference is what happens if the intermediate file does not exist.
If an ordinary file b does not exist, and make considers a target that depends
on b, it invariably creates b and then updates the target from b. But if b is
an intermediate file, then make can leave well enough alone."

This description can be made more accurate. The manual should explicitly state
that make can leave well enough done, if b is an intermediate file and the
target exists.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60904] More accurate description of intermediate files

[Dmitry Goncharov]

Additional Item Attachment, bug #60904 (project make):

File name: sv_60904_doc_clarify_intermediate.diff Size:1 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60841] misleading statement in the manual

[Dmitry Goncharov]

URL:
  

 Summary: misleading statement in the manual
 Project: make
Submitted by: dgoncharov
Submitted on: Sun 27 Jun 2021 09:57:28 PM UTC
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

The manual states in 6.10

"When make runs a recipe, variables defined in the makefile are placed into
the environment of each shell."

This statement gives impression that each make variable defined in the
makefile is placed to the env of each child, by default.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60841] misleading statement in the manual

[Dmitry Goncharov]

Additional Item Attachment, bug #60841 (project make):

File name: sv_60841_doc_fix.diff  Size:1 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #47880] Allow updates to .INCLUDE_DIRS to change search path

[Dmitry Goncharov]

Follow-up Comment #11, bug #47880 (project make):

> Can you use this?:
> include $(CURDIR)/foo.mk


This indeed suppresses the lookup.

My opinion is that the users should not have to know this detail. The behavior
should preferably be optimial for the most common scenarios.
Also, most (as far as i can tell) existing makefiles do not do this.


> this might be better considered a question of disabling the search path on a
per-include basis

Is there a need for such flexibility? A command line switch or +I  get the job
done and relieve the users from having to change the makefiles.

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #47880] Allow updates to .INCLUDE_DIRS to change search path

[Dmitry Goncharov]

Follow-up Comment #13, bug #47880 (project make):

> > My opinion is that the users should not have to know this detail.

> I didn't realize you were wearing your 'user' hat! 

My bad. By "users" here (and in other places) i meant make users, people who
write makefiles. In other words, when a user writes a makefile he should not
have to know that

depfiles:=$(obj:.o=.d)
include $(depfiles)

is less efficient than

depfiles:=$(obj:.o=.d)
depfiles:=$(addprefix $(CURDIR)/,$(depfiles))
include $(depfiles)

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #60435] Chained pattern rules with multiple targets not removing all intermediate files

[Dmitry Goncharov]

Additional Item Attachment, bug #60435 (project make):

File name: sv60435_fix.diff   Size:3 KB


File name: sv60435_doc.diff   Size:0 KB


File name: sv60435_tests.diff Size:5 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60435] Chained pattern rules with multiple targets not removing all intermediate files

[Dmitry Goncharov]

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

i attached 3 patches, the fix, tests and a fix in the doc.
Thanks for your report.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #47880] Allow updates to .INCLUDE_DIRS to change search path

[Dmitry Goncharov]

Follow-up Comment #9, bug #47880 (project make):

> But, maybe it's better to grab that bull by the horns.

>From the user's point of view, it may indeed be better to have a single
interface (MAKEFLAGS), which controls the behavior from the makefile.

> Regarding removing default directories, I wonder what people think of using
something like "-I-" to mean "delete all known include directories up to here
and start over with a fresh set"?

That should work.
Another way is to mimics the shell and use the + sign. +I/usr/include removes
/usr/include.

> It just seems to me that this issue of default include paths is too
minor/rarely problematic to waste an entire command line option on it :).

One trouble of this default is, when your dep files are missing, make does a
fs access per default directory for each missing dep file.
Another trouble is that, as far as i can tell, this default hurts most of the
users to benefit few of them.
However, since Steven reported there are makefile which use this,  i agree,
the default needs to stay.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59956] Recipes inside conditionals can break the parser

[Dmitry Goncharov]

Follow-up Comment #8, bug #59956 (project make):

i mean, the user would tell make through some option (a special target or even
presence of ".else" in the makefile) "this makefile uses .else, rather then
else". make then would not consider "else" a keyword.
The keyword does not have to be ".else". It could be e.g. "otherwise". With
"otherwise" there is no need to prefix all conditionals with a ".".


___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #60297] optimize autodeps

[Dmitry Goncharov]

Follow-up Comment #8, bug #60297 (project make):

i read that article several times and indeed found it interesting.
In fact, i was using the technique described in your article, until my use
cases forced me to come up with the technique described here.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60297] optimize autodeps

[Dmitry Goncharov]

Follow-up Comment #12, bug #60297 (project make):

> Yes, I'm saying we already have a way to mark things "not intermediate"
(.SECONDARY)  The only difference between that and a brand new
.NOTINTERMEDIATE you have proposed is that .SECONDARY doesn't handle patterns
and .NOTINTERMEDIATE does. 

Paul, this must be some sort of blindness on my side. I cannot see how
.SECONDARY can be used to mark files as not intermediate.
As far as i can see, .SECONDARY does the opposite, it marks files as
intermediate. With the only difference from .INTERMEDIATE is that the files
are not getting removed.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60297] optimize autodeps

[Dmitry Goncharov]

Follow-up Comment #14, bug #60297 (project make):

Let me provide a verbose description of .NOTINTERMEDIATE here.


This piece of make code allows to get rid from include directive with
generated dep files.

Motivation for this piece of make code is described as 1,2,3 and 4 in update
6.


.SECONDEXPANSION: %.o

%.o: %.c %.d $$(file <%.d)
gcc $(CPPFLAGS) $(CFLAGS) -MD -MF $*.td -o $@ -c $<
read obj src headers <$*.td; echo "$$headers" >$*.d
touch -c $@

%.d: ;
%.h: ;

The only missing piece is that make considers .d and .h files intermediate.

In order for this piece of code to work we need to tell make that  files which
match %.d and %.h are not intermediate.

.SECONDARY allows us to prevent make from deleting these files.

But, preventing removal is not enough.

.SECONDARY prevents deletion, but the file is still intermediate and thus,
still gives make a green light to not rebuild a target when one of the
intermediate prerequisites is missing.


When a .d file or .h is missing (not deleted by make, but for some other
reason) we need to have the related rule run to generate a new .d file.


So, a mechanism is needed to accompany implicit rules to let the user mark
chosen patterns as not intermediate (not secondary, but  full opposite of
intermediate).


> But since the targets you are referring to are already intermediate this
isn't an issue. 

It is an issue. Because as long as .d and .h files are intermedaite make won't
rebuild, if some .d or .h file is missing.


> As far as I can tell, that's the purpose of the .NOTINTERMEDIATE target you
introduced: to prevent files from being removed so that $(file ...) can read
them.

This is one of 2 purposes of .NOTINTERMEDIATE. The other purpose is to force a
rebuild when .d or .h file is missing. That's why there are these 2 rules.
%.d: ;
%.h: ;


i am not describing why a rebuild is needed when .d or .h file is missing. You
already described that well in your Auto-Dependency Generation article.

Hope this makes it clear.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60297] optimize autodeps

[Dmitry Goncharov]

Follow-up Comment #17, bug #60297 (project make):

> Just a note, in various examples you give prerequisites to the
.SECONDEXPANSION target; these are ignored.

Indeed, i was thinking about having this feature and added %.o, but should not
have.


> there's already a lot of complexity around intermediate/secondary/etc. files
:)

agree



> The first is for %.h.  However, this is not really necessary as far as I can
tell.  First, all the headers will be listed (after the $(file <%.d) is
expanded) as explicit prerequisites of the target so they won't be
intermediate files anyway.

i was thinking about whether the headers files are really intermediate in this
case. Not what the current implementation does, but are they really
intermediate? It is possible to code either way. i came to conclusion that
header files are intermediate, because make learns about them through stem
expansion in $(file <%.d). Since the %.d file, that the headers file come
from, is intermediate, header files are also intermediate.







> Second, headers are almost always source files (not built by make and so not
eligible to be removed).

agree

> The only time a source file would be removed is if the user deleted it,
which is why the %.h pattern exists: solely as a way to keep make from
complaining until the .d file can be rebuilt and the deleted header
disappears.

agree

> In the rare situations where a header is an intermediate file (built from
something else) you currently need to list it as a specific prerequisite
anyway and people seem OK with that.

There are situations where it is difficult for the user to list files (header
files or otherwise) explicitly. That's when implicit rules save us.


> The second is for %.d.  Assuming we have some variable or set of variables
that lists all the object files to be built, which almost all makefiles must
have or can have cheaply, we don't really need this one because we can force
all the %.d files to be not intermediate by mentioning them somewhere as a
prerequisite to some target.

I agree that explicitly listing all dep files eliminates a need for %.d
pattern. There are situation when it is difficult. I presented some such
situations in update 6. Obtaining this list usually comes with runtime cost of
reading the filesystem and additional code in the makefile.

> I will agree that there's something nice about being able to just mark all
%.d files as not intermediate without having to know all the .o files in a
variable like this.  But is it worth the extra complexity? 

i look at this as not "something nice". i look at .NOTINTERMEDIATE as a
missing feature in make interface.

When the user asks "i am using implicit rules, how can i ensure that files
which match a specific pattern are not intermediate?" the usual answer is "you
can work around with listing all of them explicitly". If the user can list
them explicitly, why use implicit rules?


Implementation wise there is additional code.
On the other hand, i feel, .NOTINTERMEDIATE simplifies make interface.
We can now describe make user interface as presented in update 10.
Let us repeat it here

1. make provides explicit rules.
2. make provides .INTERMEDIATE to accompany explicit rules to let the user
mark a target of choice as intermediate, when it otherwise would be not
intermediate.
3. make provides pattern rules with implicit search.
4. make provides .NOTINTERMEDIATE to accompany implicit rules to let the user
mark a pattern of choice as not intermediate, when it otherwise would be
intermediate. 


i think of .SECONDARY as of a parametrized .INTERMEDIATE, rather than a part
of this interface.
i suspect, had .NOTINTERMEDIATE existed since day 1, .SECONDARY may never have
been implemented and the code base would have been simpler.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60297] optimize autodeps

[Dmitry Goncharov]

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

sv60297_notintermediate.diff is implementation of special target
.INTERMEDIATE.

(file #51149, file #51150, file #51151)
___

Additional Item Attachment:

File name: sv60297_notintermediate.diff   Size:6 KB
   


File name: sv60297_notintermediate_test.diff Size:3 KB
   


File name: sv60297_notintermediate_doc.diff Size:0 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/