[PATCH] configure.ac: Fix gettimeofday check for C99 compilers

[Florian Weimer]

* configure.ac (HAVE_GETTIMEOFDAY): Avoid reference to undeclared
exit function.
---
 configure.ac | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index f6919a7..5897ae5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -127,8 +127,8 @@ AC_CACHE_CHECK([for standard gettimeofday], 
[ac_cv_func_gettimeofday],
   int main ()
   {
 struct timeval t; t.tv_sec = -1; t.tv_usec = -1;
-exit (gettimeofday (&t, 0) != 0
-  || t.tv_sec < 0 || t.tv_usec < 0);
+return gettimeofday (&t, 0) != 0
+  || t.tv_sec < 0 || t.tv_usec < 0;
   }]])],
   [ac_cv_func_gettimeofday=yes],
   [ac_cv_func_gettimeofday=no],
-- 
2.21.0


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

[bug #56834] PATH not honored when --disable-posix-spawn is not used

[Paul D. Smith]

Update of bug #56834 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Medium Effort  

___

Follow-up Comment #1:

I've pushed a fix for this issue.  It will be available in the next release of
GNU make.  Thanks for testing!

___

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

Re: patch to fix features/archives test 10 on sunos

[Paul Smith]

On Mon, 2019-09-09 at 22:30 -0400, Dmitry Goncharov via Bug reports and
discussion for GNU make wrote:
> ar add output is system dependent.

Thanks Dmitry; I had already made basically that same change.  See the
latest Git master (pushed this morning).

I plan to make a new release candidate this week.  I was going to do it
this past weekend but unfortunately I needed to do some gnulib-related
work (actually Bruno ended up doing most of the work) first.

Cheers!


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

Re: patch to fix features/archives test 10 on sunos

[Eli Zaretskii]

> From: Paul Smith 
> Date: Tue, 10 Sep 2019 08:36:24 -0400
> 
> I plan to make a new release candidate this week.

Did you have a chance to review the patch I proposed in
https://lists.gnu.org/archive/html/bug-make/2019-08/msg00106.html?
I'd like to install it.

Also, regarding SV 56449: are you okay with reverting that change,
given the discussion and OP's agreement with me?

Thanks.

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

Re: patch to fix features/archives test 10 on sunos

[Paul Smith]

On Tue, 2019-09-10 at 17:47 +0300, Eli Zaretskii wrote:
> > From: Paul Smith 
> > Date: Tue, 10 Sep 2019 08:36:24 -0400
> > 
> > I plan to make a new release candidate this week.
> 
> Did you have a chance to review the patch I proposed in
> https://lists.gnu.org/archive/html/bug-make/2019-08/msg00106.html?
> I'd like to install it.

Oh I already made that change... plus in another place that did similar
things.  Sorry I should have added a note about it.

> Also, regarding SV 56449: are you okay with reverting that change,
> given the discussion and OP's agreement with me?

Yes, that's fine.

I do think there's some uncleanliness about this.  It's upsetting that
Windows behaves so differently between the command line and batch file.
It makes it very difficult to implement any sort of batch mode
fallback.  Oh well.


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

Windows error messages

[Paul Smith]

It's always annoyed me that the Windows error messages generated by
make are so much different (and, arguably, less understandable) than
the ones it generates on other platforms.

For example on GNU/Linux:

! make: foobar: No such file or directory
! make: *** [work/misc/general4.mk.7;3: all] Error 127

But on Windows:

! process_begin: CreateProcess(NULL, foobar, ...) failed.
! make (e=2): The system cannot find the file specified.
! make: *** [work/misc/general4.mk.7;3: all] Error 2

Aside from the error code, is there a good reason to show this special
process_begin() message on Windows instead of just using the same error
reporting facilities that make uses on other platforms?

If we did I imagine it would look something like this:

! make: foobar: The system cannot find the file specified.
! make: *** [work/misc/general4.mk.7;3: all] Error 2

I'd really like to make this change if acceptable to the Windows folks
out there.

Cheers!


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

[bug #56449] job.c (construct_command_argv_internal): Must use shell if '%' character is present in recipe line

[Eli Zaretskii]

Update of bug #56449 (project make):

Severity:  3 - Normal => 1 - Wish   
  Status:   Fixed => Wont Fix   
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM

___

Follow-up Comment #13:

Per recent discussions, I've now reverted the fix for this bug, and I'm
closing it as "wont fix".


___

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

Re: patch to fix features/archives test 10 on sunos

[Eli Zaretskii]

> From: Paul Smith 
> Cc: dgoncha...@users.sf.net, bug-make@gnu.org
> Date: Tue, 10 Sep 2019 11:47:35 -0400
> 
> On Tue, 2019-09-10 at 17:47 +0300, Eli Zaretskii wrote:
> > > From: Paul Smith 
> > > Date: Tue, 10 Sep 2019 08:36:24 -0400
> > > 
> > > I plan to make a new release candidate this week.
> > 
> > Did you have a chance to review the patch I proposed in
> > https://lists.gnu.org/archive/html/bug-make/2019-08/msg00106.html?
> > I'd like to install it.
> 
> Oh I already made that change... plus in another place that did similar
> things.  Sorry I should have added a note about it.

OK, thanks.  No harm done.

> > Also, regarding SV 56449: are you okay with reverting that change,
> > given the discussion and OP's agreement with me?
> 
> Yes, that's fine.

Done.

> I do think there's some uncleanliness about this.  It's upsetting that
> Windows behaves so differently between the command line and batch file.
> It makes it very difficult to implement any sort of batch mode
> fallback.  Oh well.

Agreed.

Btw, I see you added support for dirent.d_type for dirent functions
emulation when compiling with MSVC, but I don't think Make uses this
anywhere, except when building with glibc.  In particular, the
HAVE_STRUCT_DIRENT_D_TYPE macro doesn't seem to be referenced
anywhere.  Did I miss something?

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

wildcard ignores dangling symlinks, and .MAKEPID

[David Boyce]

These are two minor topics and I'm not asking for anything to be done about
either for the upcoming release but I thought it couldn't hurt to mention
them for discussion. First, the $(wildcard ...) function appears to rely on
stat(), not lstat(), which means it considers a dangling symlink to not
exist (test case below). This can be a pain in "make clean" scenarios and
other corner cases. One could imagine fixing this in the code with (say) a
$(wildcardl ...) function but it may be sufficient to address it in the
documentation. I've been able to work around any problems this causes by
use of $(shell ls ...).

Second: now that make has $(file ...) and can create files internally, not
just via a recipe, there is the possibility of race conditions such as two
make processes creating the same file and no internal way to uniqify them.
Would it make sense to publish a new variable like $(.MAKEPID) for that
use? I thought I had a test case for this but the problem turned out to be
different: however it still seems like a theoretical possibility. A
.MAKEPID variable could also be useful in strace etc scenarios.

Thanks,
David

Test case for wildcard:

$ ls -lrt
total 4
-rw-rw-r-- 1  users 120 Sep 10 09:05 Makefile
-rw-rw-r-- 1  users   0 Sep 10 09:06 target
lrwxrwxrwx 1  users   6 Sep 10 09:06 testlink -> target

$ cat Makefile
ifneq ($(wildcard testlink),)
  $(warning testlink is present)
else
  $(warning testlink does not exist)
endif
all:;@:

$ make
Makefile:2: testlink is present

$ rm target

$ make
Makefile:4: testlink does not exist
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Windows error messages

[Eli Zaretskii]

> From: Paul Smith 
> Date: Tue, 10 Sep 2019 11:58:59 -0400
> 
> ! process_begin: CreateProcess(NULL, foobar, ...) failed.
> ! make (e=2): The system cannot find the file specified.
> ! make: *** [work/misc/general4.mk.7;3: all] Error 2
> 
> Aside from the error code, is there a good reason to show this special
> process_begin() message on Windows instead of just using the same error
> reporting facilities that make uses on other platforms?

The reasons are mostly historical.  The Windows sub-process code is
different from Posix and quite tricky, due to a few corner cases, like
running batch files etc., see the comments there.  In some situations,
seeing the actual way CreateProcess was called can help, because it is
not always easy to guess that in every use case, due to the
complications with quotes, special shell characters, etc.

> If we did I imagine it would look something like this:
> 
> ! make: foobar: The system cannot find the file specified.
> ! make: *** [work/misc/general4.mk.7;3: all] Error 2
> 
> I'd really like to make this change if acceptable to the Windows folks
> out there.

Fine with me, but maybe leave the current detailed message available
under --debug?

Thanks.

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

Re: patch to fix features/archives test 10 on sunos

[Paul Smith]

On Tue, 2019-09-10 at 19:17 +0300, Eli Zaretskii wrote:
> Btw, I see you added support for dirent.d_type for dirent functions
> emulation when compiling with MSVC, but I don't think Make uses this
> anywhere, except when building with glibc.  In particular, the
> HAVE_STRUCT_DIRENT_D_TYPE macro doesn't seem to be referenced
> anywhere.  Did I miss something?

It's used in both src/dir.c and in lib/glob.c.

I believe Windows uses GNU make's embedded lib/glob.c and without this
it doesn't properly handle globbing of directories-only by appending
"/".

Cheers!


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

Re: patch to fix features/archives test 10 on sunos

[Eli Zaretskii]

> From: Paul Smith 
> Cc: bug-make@gnu.org
> Date: Tue, 10 Sep 2019 12:35:18 -0400
> 
> > Btw, I see you added support for dirent.d_type for dirent functions
> > emulation when compiling with MSVC, but I don't think Make uses this
> > anywhere, except when building with glibc.  In particular, the
> > HAVE_STRUCT_DIRENT_D_TYPE macro doesn't seem to be referenced
> > anywhere.  Did I miss something?
> 
> It's used in both src/dir.c and in lib/glob.c.

Right.  I looked in make-4.2.90, instead of in Git.

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

Make error messages

[Paul Smith]

I've gone through a few iterations of the format of make error messages
and I'm still not happy.

Originally we didn't put the makefile name/linenumber in the error at
all when a recipe failed (we did for syntax errors in makefiles of
course).  Then someone asked for make to show a reference to the recipe
that failed when make detected an error, so I changed it to this:

  make: *** [Makefile:3: myprog.o] Error 1

The idea was to use the same format that the compiler, etc. used so
that (for example) Emacs compile mode would be able to jump to errors.

That didn't work, however, because particularly in recursive make the
makefile name is likely not qualified with a path, but the current
working directory when the build is invoked is not the same as the one
where make is invoked--thus "Makefile" is at best ambiguous.

So now I've changed the output to use a semicolon between the name and
the line number to try to "hide" this from Emacs compile mode:

  make: *** [Makefile;3: myprog.o] Error 1
 ^
This fixed the problem at least for Emacs compile mode; it no longer
recognizes this as an error line.  But it still seems suboptimal to me.

I've been wondering if we shouldn't make an attempt to show the
"correct" path to the makefile in these error messages.  The way I was
imagining it could work is something like this:

(a) when make is invoked it looks for special environment variable,
like MAKE_ROOTDIR or something.  If that value is set it is remembered.
If that variable is not set then it is set to the value of
current_directory (already computed in main() using getcwd()) and
exported.  The result is that MAKE_ROOTDIR should be the current
working directory of the user when they invoked the top-level make,
even if we're in a recursive make.

(b) when make wants to generate an error message containing the name of
the current makefile, it computes the fully-qualified path of the
makefile then strips off the prefix MAKE_ROOTDIR and prints that as the
name of the makefile.  Of course if the path doesn't start with
MAKE_ROOTDIR we print the fully-qualified path.

Obviously there are some weirdnesses here... for example the ever-
present issue of symlinks yielding multiple different paths to the same
directory, but in that situation you'd simply get the fully-qualified
makefile path.

Also, if you had a script that changed directory then invoked the root
make it would not work... but your script could pre-set $MAKE_ROOTDIR
before starting make.

Or we could always print the fully-qualified path but that may look
gross.

This would also allow us to go back to the error message with a ":"
since Emacs could jump to the correct place in the correct makefile.

I dunno.  Thoughts?


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

patch to fix grouped_targets test 1

[Dmitry Goncharov via Bug reports and discussion for GNU make]

Good morning.

echo -n is not portable.
Certain implementations of echo everything, including -n.
This makes test 1 of grouped_targets fail.

regards, Dmitry

diff --git a/tests/scripts/features/grouped_targets
b/tests/scripts/features/grouped_targets
index ef9366b..4d2c9d2 100644
--- a/tests/scripts/features/grouped_targets
+++ b/tests/scripts/features/grouped_targets
@@ -9,9 +9,9 @@ $details = "Here we test for requirements like\n"
 run_make_test(q{
 .PHONY: all
 &:;
-all: ;@echo -n
+all: ;@echo foo
 },
-'', "");
+'', "foo");

 # Parsing: &: works not preceded by whitespace.
 run_make_test(q{

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

vpathplus test 2 patch

[Dmitry Goncharov via Bug reports and discussion for GNU make]

The new hashing mechanism hashes differently on big vs little endian.
This makes vpathplus test 2 fail, because the order of intermediate files
inter.b and inter.c is now dependent on endiannes.

regards, Dmitry

diff --git a/tests/scripts/features/vpathplus b/tests/scripts/features/vpathplus
index 8e723fe..3ab9c05 100644
--- a/tests/scripts/features/vpathplus
+++ b/tests/scripts/features/vpathplus
@@ -96,10 +96,12 @@ $make_name: *** [$makefile;13: notarget.b] Error 1

 push(@touchedfiles, "inter.a", "inter.b");

+my $be = pack("L", 1) eq pack("N", 1);
+my $intfiles = $be ? "inter.c inter.b" : "inter.b inter.c";
 $answer = "cat ${VP}inter.d > inter.c
 cat inter.c > inter.b 2>/dev/null || exit 1
 cat inter.b > inter.a
-rm inter.b inter.c
+rm $intfiles
 ";
 &compare_output($answer,&get_logfile(1));

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

Re: Make error messages

[Andreas Schwab]

On Sep 10 2019, Paul Smith  wrote:

> That didn't work, however, because particularly in recursive make the
> makefile name is likely not qualified with a path, but the current
> working directory when the build is invoked is not the same as the one
> where make is invoked--thus "Makefile" is at best ambiguous.

But isn't that the same situation as with any other error message in a
recursive make, which Emacs already handles correctly (with the help of
make --print-directory)?

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

Re: vpathplus test 2 patch

[Andreas Schwab]

On Sep 10 2019, Dmitry Goncharov via Bug reports and discussion for GNU  make 
 wrote:

> The new hashing mechanism hashes differently on big vs little endian.

Should this be considered as a bug?

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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