Re: Regression on Cygwin: Problems with parallel make in 4.4

2023-02-20 Thread Paul Smith
On Mon, 2023-02-20 at 20:21 -0500, Ken Brown wrote: > Parallel make is still not working reliably.  I've just discovered > that my TeX Live build logs have several occurrences of the following > warning: > >    jobserver unavailable: using -j1.  Add '+' to parent make rule. > > This has been

[bug #63821] Switch -r fails to disable default suffix rules.

2023-02-20 Thread Paul D. Smith
Update of bug #63821 (project make): Status:None => Fixed Open/Closed:Open => Closed Component Version: SCM => 4.3 Fixed Release:

[bug #63821] Switch -r fails to disable default suffix rules.

2023-02-20 Thread Dmitry Goncharov
Follow-up Comment #5, bug #63821 (project make): > The title is slightly misleading Hopefully, subsequent description made it clear. > Curious why you decided to install the default suffix rules after snap_deps() @dgoncharov . i wanted to install default suffix rules as close to

Re: Regression on Cygwin: Problems with parallel make in 4.4

2023-02-20 Thread Ken Brown
On 2/19/2023 9:29 AM, Paul Smith wrote: I will change the default setting of the jobserver to use "pipe" on Cygwin, at least for now. Parallel make is still not working reliably. I've just discovered that my TeX Live build logs have several occurrences of the following warning: jobserver

[bug #63821] Switch -r fails to disable default suffix rules.

2023-02-20 Thread Paul D. Smith
Follow-up Comment #4, bug #63821 (project make): Curious why you decided to install the default suffix rules after snap_deps() @dgoncharov . That doesn't feel right to me, was there something that didn't work right if you did it between defining the makeflags and snap_deps(), rather than after?

RE: Handling references to invalid variables

2023-02-20 Thread rsbecker
On Monday, February 20, 2023 2:50 PM, Paul Smith wrote: >On Mon, 2023-02-20 at 14:20 -0500, rsbec...@nexbridge.com wrote: >> I think you need to be able to return to a compatible mode for some >> users. Having an option like --undefined-variables=warn or -- >> undefined-variables=error (the

Re: Handling references to invalid variables

2023-02-20 Thread Paul Smith
On Mon, 2023-02-20 at 14:20 -0500, rsbec...@nexbridge.com wrote: > I think you need to be able to return to a compatible mode for some > users. Having an option like --undefined-variables=warn or -- > undefined-variables=error (the default) or --undefined- > variables=ignore would be prudent. Hm.

RE: Handling references to invalid variables

2023-02-20 Thread rsbecker
On February 20, 2023 2:11 PM, Paul Smith wrote: >In the next major release (not the upcoming 4.4.1 release but the one after >that) I >plan to implement notifying users of invalid variable references; for example >variable names containing whitespace. > >So, a makefile like this for example: > >

Re: Handling references to invalid variables

2023-02-20 Thread David A. Wheeler
> On Feb 20, 2023, at 2:11 PM, Paul Smith wrote: > > In the next major release (not the upcoming 4.4.1 release but the one > after that) I plan to implement notifying users of invalid variable > references; for example variable names containing whitespace. > ... > > The question is, should

Handling references to invalid variables

2023-02-20 Thread Paul Smith
In the next major release (not the upcoming 4.4.1 release but the one after that) I plan to implement notifying users of invalid variable references; for example variable names containing whitespace. So, a makefile like this for example: all: ; echo $(cat foo) will notify the user about the

[bug #63821] Switch -r fails to disable default suffix rules.

2023-02-20 Thread Dmitry Goncharov
Follow-up Comment #2, bug #63821 (project make): A correction: After parsing makefiles the patch appends the default suffix rules to suffix_file->deps only if there is no user defined rules in the makefile. ___ Reply to this item at:

[bug #63821] Switch -r fails to disable default suffix rules.

2023-02-20 Thread Dmitry Goncharov
Additional Item Attachment, bug #63821 (project make): File name: sv63821_fix.diff Size:3 KB File name: sv63821_test.diff Size:2 KB

[bug #63821] Switch -r fails to disable default suffix rules.

2023-02-20 Thread Dmitry Goncharov
Follow-up Comment #1, bug #63821 (project make): Setting -r in MAKEFLAGS in makefile fails to the disable default suffix rules. $ ls hello.c makefile $ cat makefile MAKEFLAGS+=-r .SUFFIXES: .c .o all: hello.o $ make-4.4 cc-c -o hello.o hello.c $ $ rm hello.o $ make-4.4 -r make-4.4:

[bug #63821] Switch -r fails to disable default suffix rules.

2023-02-20 Thread Dmitry Goncharov
URL: Summary: Switch -r fails to disable default suffix rules. Group: make Submitter: dgoncharov Submitted: Mon 20 Feb 2023 05:52:08 PM UTC Severity: 3 - Normal

Re: GNU Make 4.4.0.91 on Cygwin

2023-02-20 Thread Eli Zaretskii
> From: Paul Smith > Cc: br...@clisp.org, bug-make@gnu.org > Date: Mon, 20 Feb 2023 10:36:07 -0500 > > Of course "testing on Windows" can mean many different things as there > are so many possible environments "on Windows". I only run one Windows > environment: (a) Windows 10/11 in a VM, (b)

Re: GNU Make 4.4.0.91 on Cygwin

2023-02-20 Thread Paul Smith
On Mon, 2023-02-20 at 14:47 +0200, Eli Zaretskii wrote: > How do you conclude that this "works on Windows"? Before I make a release I test on various systems and the regression test suite must pass with no failures. One of the systems I test on is Windows, so if a release comes out and a test is

Re: GNU Make 4.4.0.91 on Cygwin

2023-02-20 Thread Eli Zaretskii
> From: Paul Smith > Date: Sun, 19 Feb 2023 14:59:35 -0500 > > On Sun, 2023-02-19 at 20:32 +0100, Bruno Haible wrote: > > All "Device or resource busy" failures are gone. Only the 1 failure > > in category 'misc/general4' is still present. > > Hm. This is a test of this: >