[bug #63157] Unlink temporary files.

2022-10-20 Thread Martin Dorey 
Follow-up Comment #26, bug #63157 (project make):

Ach, it did reproduce for me, with or without Dmitry's modification.  I was
just looking in the wrong place, despite Frank providing copy-and-paste
instructions on where to look.  Perhaps I'd just read about MAKE_TMPDIR and
assumed that they'd end up in the nice clean directory I'd made for them, as
they do with:

 MAKE_TMPDIR=$(pwd) make -j2 -O 2>&1 | :

Sorry for the mislead.


___

Reply to this item at:

  

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

[bug #63157] Unlink temporary files.

2022-10-20 Thread Dmitry Goncharov 
Follow-up Comment #25, bug #63157 (project make):

This may not always reproduce, because there is a race between make writing
its output to the pipe and the reader exiting.
Sigpipe is sent when the reader exits before make is able to write its
output.
However, if you change it like this

echo 'all:; sleep 2' | make -f- -j2 -O |:

it'll reproduce.

Thanks for you report, Frank.
i opened https://savannah.gnu.org/bugs/index.php?63248 and attached a patch.


___

Reply to this item at:

  

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

[bug #63248] Ignore sigpipe.

2022-10-20 Thread Dmitry Goncharov 
Additional Item Attachment, bug #63248 (project make):

File name: sv63248.diff   Size:1 KB




___

Reply to this item at:

  

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

[bug #63248] Ignore sigpipe.

2022-10-20 Thread Dmitry Goncharov 
Follow-up Comment #1, bug #63248 (project make):

A user reported that make leaves temporary files behind when killed by
sigpipe.



$ ls tmp/
$ echo 'all:; sleep 2' | ~/src/gmake/make/l64/make -f- -j2 -O |:
$ ls tmp
GmIDqB2Q  GmyW1CcO
$ rm tmp/*
$ # this make ignores sigpipe
$ echo 'all:; sleep 2' | ~/src/gmake/make/l64/make -f- -j2 -O |:
fwrite(): Broken pipe
make: write error: stdout
$ ls tmp/
$


The bug report is here
https://lists.gnu.org/archive/html/bug-make/2022-10/msg00160.html


___

Reply to this item at:

  

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

[bug #63248] Ignore sigpipe.

2022-10-20 Thread Dmitry Goncharov 
URL:
  

 Summary: Ignore sigpipe.
 Project: make
   Submitter: dgoncharov
   Submitted: Thu 20 Oct 2022 09:47:11 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: POSIX-Based
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Thu 20 Oct 2022 09:47:11 PM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

  

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

[bug #63241] implement "exit" in makefile parsing

2022-10-20 Thread Dmitry Goncharov 
Follow-up Comment #1, bug #63241 (project make):

i'd prefer to keep make language free of imperative constructs. Once you give
them "if", they'll want "for" and "break" and "exit", etc.
In my experience, it is better to avoid code like

ifneq ($(filter %clean clobber,$(MAKECMDGOALS)),).

This piece of code is an example of an imperative construct.

There are make tools, like target specific variables, implicit rules, pattern
matching, etc which often solve the task at hand and reduce complexity.
 


___

Reply to this item at:

  

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

Re: GNU make 4.3.91 on Cygwin

2022-10-20 Thread Bruno Haible 
Paul Smith wrote:
> > > On Cygwin 2.9.0 (64-bit), compilation works fine, but there are 11
> > > test failures.
> 
> Is it feasible to run these tests, particularly the Windows ones, on
> the GNU make 4.3 release package?

Sure. Find attached the results for GNU make 4.3 on the same Cygwin:
2 failures
  work/features/exec.diff
  work/options/dash-l.diff

> I'd just like to make sure I didn't
> make things significantly worse there.

In 4.3.91 I saw 11 failures:
  work/features/exec.diff
  work/features/jobserver.diff
  work/features/jobserver.diff.1
  work/features/jobserver.diff.11
  work/features/jobserver.diff.2
  work/features/jobserver.diff.6
  work/features/parallelism.diff.12
  work/features/parallelism.diff.4
  work/features/recursion.diff
  work/functions/shell.diff.20
  work/misc/general4.diff.9

> I could remove the
> MinGW shutils from my PATH and get the suite working without them but I
> don't want to undertake that for this release.

For the Cygwin port, this wouldn't help.

For the mingw port, it sounds like Eli already has some patches (or at least
he knows which places need to be patched) [1].

Bruno

[1] https://lists.gnu.org/archive/html/bug-make/2022-10/msg00168.html


cygwin-make4.3-failures.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.91 on Cygwin

2022-10-20 Thread Paul Smith 
On Tue, 2022-10-18 at 23:37 -0400, Paul Smith wrote:
> On Wed, 2022-10-19 at 03:01 +0200, Bruno Haible wrote:
> > On Cygwin 2.9.0 (64-bit), compilation works fine, but there are 11
> > test failures.
> 
> I don't test or support cygwin myself so it's not surprising.  The
> cygwin team apparently has a set of patches that they maintain for
> GNU make but I'm not sure what they are.
> 
> Getting a KGO-based test suite like GNU make's, to work on systems
> like Windows w/ Cygwin etc., is a tall order.

Is it feasible to run these tests, particularly the Windows ones, on
the GNU make 4.3 release package?  I'd just like to make sure I didn't
make things significantly worse there.  There was some puttering with
backslashes recently that _shouldn't_ have made any difference but...

I suppose at some point I'll have to figure out how to work with
Cygwin.  I don't have access to a Windows system where I'm free to
install whatever I want unfortunately.  About all I can easily test is
compiling with MSVC using the build_w32.bat script.  I could remove the
MinGW shutils from my PATH and get the suite working without them but I
don't want to undertake that for this release.

Re: GNU make 4.3.91 on mingw

2022-10-20 Thread Eli Zaretskii 
> From: Bruno Haible 
> Date: Wed, 19 Oct 2022 03:06:51 +0200
> 
> On mingw (on Windows 10 in a Cygwin dev environment), compilation works
> fine, but there are 91 test failures.

FTR: I get only 2 failures in options/dash-q (and for a reason that is
a non-issue: temporary batch files are not removed).  But the test
suite needs to be heavily patched to work with the MinGW port and the
cmd.exe shell.  However, most changes are trivial: different quoting,
different syntax of environment variable expansion, need to use the
GNU 'echo' instead of the shell builtin, .dll extension instead of .so
for loaded extensions, etc.