Re: make manual feedback

On Mon, 2024-01-22 at 21:16 +, David Apps wrote: > I have some feedback about the document at the following address: Thanks for your feedback. I applied all these changes, or some form of them, except: > > Do not install executables here in this directory > > Perhaps delete "here". > > > A

Re: make-4.3 on Linux x86_64 fails features/output-sync test

On Mon, 2023-11-27 at 15:27 -0500, Dennis Clarke via Bug reports and discussion for GNU make wrote: > GNU Make 4.3 Is the failure repeatable? Have you tried it with the latest version of GNU Make? It certainly doesn't fail on my system (which is, obviously, also running x86_64 GNU/Linux). But, t

Re: MAKE BUG

On Fri, 2023-10-13 at 13:13 +0530, Nachiketa Gupta wrote: > Hi All, > MAKE version 3.8 > So my question is why does it always print -j independent of -j > value? > is some make.conf file located in our area which is overriding this > variable with -j? > I have also confirmed that with the 4.3 vers

Re: `make check -j` fails when building GNU Make from source

On Mon, 2023-04-03 at 14:36 +0200, Alejandro Colomar wrote: > -  Being part of the make targets, it would enable running them in >    parallel, taking around 1/4th the time it takes now. Up until this morning this could not work because all the tests run in the same directory and they create tempo

Re: `make check -j` fails when building GNU Make from source

Hi Paul, On 4/3/23 14:26, Paul Smith wrote: > On Sun, 2023-04-02 at 18:14 +0200, Alejandro Colomar wrote: >> I wonder if you could use the Makefile to run the tests, rather >> than calling a script from a .PHONY target that runs them all the >> time.  Why not run them only once?  You can touch emp

Re: `make check -j` fails when building GNU Make from source

On Sun, 2023-04-02 at 18:14 +0200, Alejandro Colomar wrote: > I wonder if you could use the Makefile to run the tests, rather > than calling a script from a .PHONY target that runs them all the > time.  Why not run them only once?  You can touch empty files > when a test succeeds to make make(1) ha

Re: `make check -j` fails when building GNU Make from source

On 4/2/23 16:15, Paul Smith wrote: > On Sun, 2023-04-02 at 16:13 +0200, Alejandro Colomar wrote: >> I can reproduce it by running `make check`, interrupting it >> at this specific point, and then running again `make check` >> (no -j needed): > > This is a known limitation with the test suite. I w

Re: `make check -j` fails when building GNU Make from source

On Sun, 2023-04-02 at 16:13 +0200, Alejandro Colomar wrote: > I can reproduce it by running `make check`, interrupting it > at this specific point, and then running again `make check` > (no -j needed): This is a known limitation with the test suite.

Re: `make check -j` fails when building GNU Make from source

Hi Paul, On 4/2/23 16:04, Paul Smith wrote: > On Sun, 2023-04-02 at 14:52 +0200, Alejandro Colomar wrote: >> If I build make from source and run the checks in parallel, some >> fail. Is this expected, or is it a bug in the Makefile? > > The test suite is invoked as a single target, so there's no

Re: `make check -j` fails when building GNU Make from source

On Sun, 2023-04-02 at 14:52 +0200, Alejandro Colomar wrote: > If I build make from source and run the checks in parallel, some > fail. Is this expected, or is it a bug in the Makefile? The test suite is invoked as a single target, so there's no way that enabling parallelism could impact it. Also

Re: make -t and directories

Hi Paul, On 3/11/23 15:20, Paul Smith wrote: > On Sat, 2023-03-11 at 01:54 +0100, Alejandro Colomar wrote: >> Let's say I have a build tree that has directories which are created >> during build.  The build system has some linters in a `lint` target, >> which touches files when it succeeds.  When

Re: make -t and directories

On Sat, 2023-03-11 at 01:54 +0100, Alejandro Colomar wrote: > Let's say I have a build tree that has directories which are created > during build.  The build system has some linters in a `lint` target, > which touches files when it succeeds.  When I want to lint only a > specific file, it's interes

Re: make -t and directories

Hi Dmitry, On 3/11/23 14:36, Dmitry Goncharov wrote: > On Fri, Mar 10, 2023 at 7:55 PM Alejandro Colomar > wrote: >> How about using `mkdir -p` instead of touch(1) for nonexistent files? > > mkdir -p would create a directory where a file is supposed to be. > Let's say you have hello.c, but no he

Re: make -t and directories

On Fri, Mar 10, 2023 at 7:55 PM Alejandro Colomar wrote: > How about using `mkdir -p` instead of touch(1) for nonexistent files? mkdir -p would create a directory where a file is supposed to be. Let's say you have hello.c, but no hello.o.If you run make -t it'll create an empty hello.o. Then you

Re: "make check" failure on Solaris 10 as File::Temp->newdir is missing

On 2022-10-18 20:08, Paul Smith wrote: On Tue, 2022-10-18 at 14:46 -0700, Paul Eggert wrote: Solaris 10 (supported by Oracle through January 2024) uses Perl 5.8.4. tests/README says Perl 5.004 or later is needed That is wrong. In fact the tests/README file hasn't been updated an a very long t

Re: "make check" failure on Solaris 10 as File::Temp->newdir is missing

On Tue, 2022-10-18 at 14:46 -0700, Paul Eggert wrote: > Solaris 10 (supported by Oracle through January 2024) uses Perl > 5.8.4. tests/README says Perl 5.004 or later is needed That is wrong. In fact the tests/README file hasn't been updated an a very long time (I actually forgot it was there).

Re: Make 4.3.90 breaks makefile of dtc

On Mon, Sep 26, 2022 at 8:59 AM Andreas Schwab wrote: > Try building it with make -O -j4 V=1, and watch /tmp filling with Gm* i was able to reproduce this. See https://savannah.gnu.org/bugs/index.php?63111. You correctly identified the offending rule. Thanks for your report. regards, Dmitry

Re: Make 4.3.90 breaks makefile of dtc

On Sep 23 2022, Dmitry Goncharov wrote: > The latest make from master (same as 4.3.90) builds dtc-1.6.1 Try building it with make -O -j4 V=1, and watch /tmp filling with Gm* files, and the make process growing its file table. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 01

Re: Make 4.3.90 breaks makefile of dtc

On Sep 22 2022, Dmitry Goncharov wrote: > On Thu, Sep 22, 2022 at 4:39 AM Andreas Schwab wrote: > ... >> Interestingly, this eventually runs out of file >> descriptors, because, due to -O, make keeps opening new pipes for >> synchronizing the output without closing any. Without -O, this would >>

Re: Make 4.3.90 breaks makefile of dtc

On Sep 22 2022, Paul Smith wrote: > Just to be clear when you say "the issue is" do you mean, if you remove > the unnecessary %.output pattern you don't see the error anymore? Yes. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B

Re: Make 4.3.90 RC fails 3 tests on OpenBSD 7.1 i386

Thanks for testing. On Sun, 2022-09-25 at 17:25 -0700, Mike Gran wrote: > I configured it using configure with CC=clang and no other options. > > loadapi.mk.3 and loadapi.mk.7 both complain that testapi.so failed > to load.  If there is an actual testapi.so being built, I can't > find it. > > ou

Re: Make 4.3.90 breaks makefile of dtc

On Thu, Sep 22, 2022 at 4:39 AM Andreas Schwab wrote: > There is some misbehaviour that creates an infinite loop trying to run > the bison rule. Interestingly, this eventually runs out of file > descriptors The latest make from master (same as 4.3.90) builds dtc-1.6.1 successfully for me with

Re: Make 4.3.90 breaks makefile of dtc

On Thu, 2022-09-22 at 10:54 +0200, Andreas Schwab wrote: > The issue is that the bison rule says it creates a %.output file, but > doesn't actually do that. > > %.tab.c %.tab.h %.output: %.y > @$(VECHO) BISON $@ > $(BISON) -b $(basename $(basename $@)) -d $< > > Note that no targe

Re: Make 4.3.90 breaks makefile of dtc

On Thu, Sep 22, 2022 at 4:39 AM Andreas Schwab wrote: ... > Interestingly, this eventually runs out of file > descriptors, because, due to -O, make keeps opening new pipes for > synchronizing the output without closing any. Without -O, this would > probably go on forever. Make used to synchroniz

Re: Make 4.3.90 breaks makefile of dtc

The issue is that the bison rule says it creates a %.output file, but doesn't actually do that. %.tab.c %.tab.h %.output: %.y @$(VECHO) BISON $@ $(BISON) -b $(basename $(basename $@)) -d $< Note that no target actually depends on any *.output file. -- Andreas Schwab, SUSE Labs,

Re: Make Docs Errata

> It says SECONDARY EXPANSION, while the first time the manual is referring to > the first one I think it means what it says. I'd try to suggest a rewording for clarity... but I'm not seeing how it could be clearer. Perhaps you could suggest one? From: Bug-mak

Re: Make losing jobserver tokens on Windows

On Mon, 2022-02-21 at 15:56 +0100, Magnus Ihse Bursie wrote: > I'm trying to built it from source right now (and it does not seem > complicated), but even so, an official binary makes sure I'm not > introducing any issues from my local build environment. There is no such thing as an "official bi

Re: Make losing jobserver tokens on Windows

> Date: Mon, 21 Feb 2022 15:56:37 +0100 > From: Magnus Ihse Bursie > > > I am not aware of any issues like this. However, I recommend that you > > try using the Visual Studio build of GNU make and see if that works > > better. I'm not very familiar with the Cygwin version of GNU make; > > it's

Re: Make losing jobserver tokens on Windows

>> I believe that the goal of the Cygwin port is to implement a POSIX >> layer on top of Windows, so I'm assuming that when you compile GNU >> make with Cygwin it uses the POSIX implementation of the jobserver. >> This implementation relies on certain POSIX behaviors of pipes and >> signals and it'

Re: Make losing jobserver tokens on Windows

On 2022-02-18 16:04, Paul Smith wrote: On Fri, 2022-02-18 at 10:18 +0100, Magnus Ihse Bursie wrote: make[2]: INTERNAL: Exiting with 1 jobserver tokens available; should be 24! This effectively turns the highly parallelized builds into single-threaded builds, and is absolutely detrimental for pe

Re: make re-exec regression in 'make -sf -' mode

On Sat, Feb 19, 2022 at 4:12 AM Sergei Trofimovich wrote: > Noticed the regression on lowdown-0.10.0 upstream package. ... > Bitsect points at commit 7c4e6b0299 "[SV 60595] Restart > whenever any makefile is rebuilt". Thanks for your report. I opened https://savannah.gnu.org/bugs/index.php?62088

Re: Make losing jobserver tokens on Windows

> From: Paul Smith > Date: Fri, 18 Feb 2022 10:04:08 -0500 > > I am not aware of any issues like this. However, I recommend that you > try using the Visual Studio build of GNU make and see if that works > better. I'm not very familiar with the Cygwin version of GNU make; > it's not maintained b

Re: Make losing jobserver tokens on Windows

On Fri, 2022-02-18 at 10:18 +0100, Magnus Ihse Bursie wrote: > make[2]: INTERNAL: Exiting with 1 jobserver tokens available; should > be 24! > > This effectively turns the highly parallelized builds into > single-threaded builds, and is absolutely detrimental for > performance. :-( On the flip si

Re: Make losing jobserver tokens on Windows

> Date: Fri, 18 Feb 2022 10:18:24 +0100 > From: Magnus Ihse Bursie > > So, my first question is: Is this a known problem? Are there any > workarounds/fixes to get around it? Not that I know of, no. Search of the bug database also doesn't seem to bring up anything like that. > Otherwise: Any s

RE: make -j does not work on RedHat7.7 VM

; Foster, Casey ; Levan, Mark Subject: Re: make -j does not work on RedHat7.7 VM On Thu, 2021-12-23 at 12:49 +, Zhu, Mason wrote: > In GNU Make 3.82, it seems that -j option will be finally added if > Make determines my VM has the parallel build capability. It has never been the cas

Re: make -j does not work on RedHat7.7 VM

On Thu, 23 Dec 2021 12:49:51 + "Zhu, Mason" wrote: > I checked our project make file. Yes, we are using recursive Make, but does > not explicitly set -j options in MAKEFLAGS. > > In GNU Make 3.82, it seems that -j option will be finally added if Make > determines my VM has the parallel build

Re: make -j does not work on RedHat7.7 VM

On Thu, 2021-12-23 at 12:49 +, Zhu, Mason wrote: > In GNU Make 3.82, it seems that -j option will be finally added if > Make determines my VM has the parallel build capability. It has never been the case that any version of GNU make has automatically enabled parallel builds by itself. It's al

Re: make -j does not work on RedHat7.7 VM

> Could you help to look into it? Not much, sorry. > Is this a misconfiguration in my project build environment or a bug in GNU > Make 4.2.1? Maybe you'd be convinced that it's the former if you run a test like this: martind@sirius:~/tmp/mason-zhu-2021-12-21$ cat Makefile TARGETS = a b c defau

Re: Make language

bug-make@gnu.org> > > To: "Bartol Hrg" > > Cc: bug-make@gnu.org > > Sent: Tuesday, October 12, 2021 12:25:05 PM > > Subject: Re: Make language > > > > On Tue, Oct 12, 2021 at 10:38 AM Bartol Hrg > > wrote: > > > > > > Greeting

Re: Make language

Sviđa mi se! -- Kevin R. Bulgrien - Original Message - > From: "Dmitry Goncharov via Bug reports and discussion for GNU make" > > To: "Bartol Hrg" > Cc: bug-make@gnu.org > Sent: Tuesday, October 12, 2021 12:25:05 PM > Subject: Re: Make language

Re: Make language

On Tue, Oct 12, 2021 at 10:38 AM Bartol Hrg wrote: > > Greetings > > I installed make 3.81 for Windows > > It's in d*mn Croatian! > > Now, I don't know if you noticed, but I speak English. > > I'm really displeased and agitated. > > Best regards > B. Helium Dobar dan. Vaš pošta je na Engleskom je

Re: Make language

fend your sensibilities with Croatian. From: Bug-make on behalf of Liviu Ionescu Sent: Tuesday, October 12, 2021 08:05 To: Bartol Hrg Cc: bug-make@gnu.org Subject: Re: Make language * EXTERNAL EMAIL * > On 12 Oct 2021, at 17:12, Bartol Hrg wrote: > > ... I installed

Re: Make language

On Tue, 2021-10-12 at 14:12 +, Bartol Hrg wrote: > I'm really displeased and agitated. I hope that letting us know what you saw helps you feel better!

Re: Make language

> On 12 Oct 2021, at 17:12, Bartol Hrg wrote: > > ... I installed make 3.81 for Windows ... It's in d*mn Croatian! You may try a different distribution, for example: - https://github.com/xpack-dev-tools/windows-build-tools-xpack/releases Regards, Liviu

Re: Make allows kind of multiple "alias" for the same target

> Here, we have 2 targets: > ../1/../main.o > ../2/../main.o > > In fact, this is the same target/file (taking into account relative > directories). Note that if ../1 or ../2 is a symlink to somewhere else, ../1/.. and ../2/.. aren't the same place. It's the makefile's responsibility to resolve

Re: "make -jN" requires mechanical changes to a Makefile [SOLVED]

On Mon, 14 Sep 2020 12:15:58 +0200 Bruno Haible wrote: > Henrik Carlqvist wrote: > > 2) Don't mention some of the extra targets: > > === > > all : copy1 > > > > copy1: Makefile > > install -c -m 644 Makefile copy1 > > install -c -m 644 Makefile co

Re: "make -jN" requires mechanical changes to a Makefile [SOLVED]

Henrik Carlqvist wrote: > 2) Don't mention some of the extra targets: > === > all : copy1 > > copy1: Makefile > install -c -m 644 Makefile copy1 > install -c -m 644 Makefile copy2 > install -c -m 644 Makefile copy3 > install -c -m 64

Re: "make -jN" requires mechanical changes to a Makefile [SOLVED]

On Sun, 13 Sep 2020 20:07:27 +0100 Bruno Haible wrote: > Continuing this thread from May 2019 > : > The problem was: > > How can a rule that generates multiple files be formulated so > that it works with parallel make? > > For

Re: "make -jN" requires mechanical changes to a Makefile [SOLVED]

Hi Paul, > There is a straightforward and portable way to do this even with > traditional make, it's just not as nice (but, nicer than changing all > the recipes to use test IMO! :)). > > If you have a rule like this: > > ... : > > > where generates all targets with one invocat

Re: "make -jN" requires mechanical changes to a Makefile [SOLVED]

On Sun, 2020-09-13 at 15:08 -0400, Paul Smith wrote: > ... : .sentinel ; > > .sentinel: > > @touch $@ Just to be clear, you don't have to use ".sentinel" you can use any target name, and obviously you must use a different name for each "grouping" of targets that needs

Re: "make -jN" requires mechanical changes to a Makefile [SOLVED]

> === > all : copy1 copy2 copy3 copy4 > > copy1: Makefile > { test -f copy1 && test ! copy1 -ot Makefile; } || { rm -f copy4; > $(MAKE) copies; } > copy2: copy1 > { test -f copy2 && test ! copy2 -ot copy1; } || { rm -f copy4; $(MAKE) > copies;

Re: "make -jN" requires mechanical changes to a Makefile [SOLVED]

On Sun, 2020-09-13 at 20:55 +0200, Bruno Haible wrote: > How can a rule that generates multiple files be formulated so > that it works with parallel make? > > For example, a rule that invokes bison, or a rule that invokes > a different Makefile. For simplicity, here, use a rule that > creates

Re: "make -jN" requires mechanical changes to a Makefile [SOLVED]

Bruno Haible wrote: > Continuing this thread from May 2019 > : > The problem was: > > How can a rule that generates multiple files be formulated so > that it works with parallel make? > > For example, a rule that invokes bison

Re: "make -jN" requires mechanical changes to a Makefile [SOLVED]

Continuing this thread from May 2019 : The problem was: How can a rule that generates multiple files be formulated so that it works with parallel make? For example, a rule that invokes bison, or a rule that invokes a different

Re: make-4.3: wildcard test #9 fails

> On Sun, 2020-04-05 at 16:19 +0200, Bruno Haible wrote: > > > > Building GNU make 4.3 on Ubuntu 16.04, produces one failing test: On filesystems which don't populate dirent::d_type (or on old glibc) test 7 also fails. I just asked gnulib mailing list to look at a patch. https://lists.gnu.org/arch

Re: make-4.3: wildcard test #9 fails

On Sun, 2020-04-05 at 16:19 +0200, Bruno Haible wrote: > Hi Paul, > > > > Building GNU make 4.3 on Ubuntu 16.04, produces one failing test: > > > > This is because the glob() function in the older GNU libc has a bug > > related to handling symlinks correctly. > > Gnulib provides a workaround aga

Re: make-4.3: wildcard test #9 fails

Hi Paul, > > Building GNU make 4.3 on Ubuntu 16.04, produces one failing test: > > This is because the glob() function in the older GNU libc has a bug > related to handling symlinks correctly. Gnulib provides a workaround against this bug in its 'glob' module [1]. But GNU make ships a copy of gl

Re: make-4.3: wildcard test #9 fails

On Sun, 2020-04-05 at 15:33 +0200, Bruno Haible wrote: > Building GNU make 4.3 on Ubuntu 16.04, produces one failing test: This is because the glob() function in the older GNU libc has a bug related to handling symlinks correctly.

Re: Make 4.3 permission denies docker commands

The "Error 127" part is redolent of: https://savannah.gnu.org/bugs/?57022 (Error 127 executing a script with no #!) But this report's "Permission denied" has no equivalent there. Still, the strace -f from there suggests an experiment that it would be helpful for Sandy to run here and, like the

Re: make-4.2.93 patch enhance error reporting from the test suite

On Fri, 2020-01-03 at 22:19 -0500, Dmitry Goncharov via Bug reports and discussion for GNU make wrote: > This patch enhances error reporting from the test suite. Thanks I applied this.

Re: make-4.2.93 patch port to c90

On Fri, 2020-01-03 at 23:30 -0500, Paul Smith wrote: > On Fri, 2020-01-03 at 22:21 -0500, Dmitry Goncharov via Bug reports and > discussion for GNU make wrote: > > This patch replaced a c99 piece of code with c90 code. > > This c99 piece of code does not compile with the default ./configure && > >

Re: make-4.2.93 patch fix compilation in -ansi/-std=c99 mode

On Sat, 2020-01-04 at 20:36 -0500, Dmitry Goncharov wrote: > On Sat, Jan 4, 2020 at 3:23 PM Paul Smith wrote: > > Thanks, I did something similar to this but not quite the same. > Have you pushed? I have now.

Re: make-4.2.93 patch fix compilation in -ansi/-std=c99 mode

On Sat, Jan 4, 2020 at 3:23 PM Paul Smith wrote: > Thanks, I did something similar to this but not quite the same. Have you pushed? > It's a bit strange because I don't see that same error on my system and in > fact, I don't have that code in my sys/wait.h file; I'm using GNU libc > 2.30. Maybe

Re: make-4.2.93 patch fix compilation in -ansi/-std=c99 mode

On Fri, 2020-01-03 at 22:18 -0500, Dmitry Goncharov via Bug reports and discussion for GNU make wrote: > This patch replaces __attribute__ with gmake_attribute to retain the > current behavior of getting __attribute__ removed from gmake's internal > function declartions and keep glibc declarations

Re: make-4.2.93 patch port to c90

On Fri, 2020-01-03 at 22:21 -0500, Dmitry Goncharov via Bug reports and discussion for GNU make wrote: > This patch replaced a c99 piece of code with c90 code. > This c99 piece of code does not compile with the default ./configure && > make. > Also, -std=c99 removes __attribute__. I already made s

Re: Make error messages

On Wed, 2019-09-11 at 08:44 +0200, Andreas Schwab wrote: > 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 th

Re: "make check" failure on Solaris 10 with make 4.2.91

On Sat, 2019-09-21 at 12:09 -0700, Paul Eggert wrote: > On 9/21/19 10:55 AM, Paul Smith wrote: > > perl -we 'use File::Spec; my @o = File::Spec->splitpath("../make"); > > print "@o\n"' > > It outputs a single line containing " ../ make". > > Hmm, I already wrote that, in one of my comments here:

Re: "make check" failure on Solaris 10 with make 4.2.91

On 9/21/19 10:55 AM, Paul Smith wrote: perl -we 'use File::Spec; my @o = File::Spec->splitpath("../make"); print "@o\n"' It outputs a single line containing " ../ make". Hmm, I already wrote that, in one of my comments here: https://lists.gnu.org/r/bug-make/2019-09/msg00101.html Perhaps you

Re: "make check" failure on Solaris 10 with make 4.2.91

On Mon, 2019-09-16 at 15:49 -0400, Paul Smith wrote: > Ugh, that's wrong. It should be " ../ make" (note the space before > "make"). File::Spec is not correctly splitting the directory from the > file, apparently. Bogus!! Can you try this one: > > perl -we 'use File::Spec; my @o = File::Spec

Re: "make check" failure on Solaris 10 with make 4.2.91

On Mon, 2019-09-16 at 12:23 -0700, Paul Eggert wrote: > > Can you run this and tell me what it prints: > > > >perl -we 'use File::Spec::Functions qw(splitpath); my @o = > splitpath("../make"); print "@o\n"' > > A single line " ../make". Ugh, that's wrong. It should be " ../ make" (note the

Re: "make check" failure on Solaris 10 with make 4.2.91

On 9/16/19 11:20 AM, psm...@nuodb.com wrote: On Mon, 2019-09-16 at 11:04 -0700, Paul Eggert wrote: syntax error at ./run_make_tests.pl line 473, near "or continue" Ugh. Can you change this line: -x $prog or continue; to this: -x $prog or next; Thanks, that got the tests to

Re: "make check" failure on Solaris 10 with make 4.2.91

On Mon, 2019-09-16 at 11:04 -0700, Paul Eggert wrote: > syntax error at ./run_make_tests.pl line 473, near "or continue" Ugh. Can you change this line: -x $prog or continue; to this: -x $prog or next; ? That's a dumb syntax error. Too many different languages. However, I don't

Re: Make error messages

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 be

Re: [make-4.2.90] functions/wildcard failed on Solaris 11.3 x86/x64

On Fri, 2019-08-30 at 00:38 +0900, Kiyoshi KANAZAWA wrote: > But, there are also N/A: > functions/guile . N/A > misc/close_stdout ... N/A > vms/library . N/A > > I do not know if

Re: [make-4.2.90] functions/wildcard failed on Solaris 11.3 x86/x64

Hi, Paul. > Can you let me know which compiler you were using to build GNU make? It is Oracle developerstudio12.6. $ Make check says 1 Test in 1 Category Failed (See .diff* files in work dir for details) :-( But, there are also N/A: functions/guile . N/A m

Re: [make-4.2.90] functions/wildcard failed on Solaris 11.3 x86/x64

On Thu, 2019-08-29 at 23:05 +0900, Kiyoshi KANAZAWA wrote: > Tried make-4.2.90 and found "functions/wildcard" fails. Yep, this is a known issue. Good to know that was the only one though. It's interesting Paul is seeing so many more failures on Solaris 10. Can you let me know which compiler you

Re: "make -jN" requires mechanical changes to a Makefile

> Howard Chu wrote: > > >> Example with one rule creating 4 files: > > >> > > >> all : copy1 > > >> > > >> copy1: Makefile > > >> install -c -m 644 Makefile copy1 > > >> install -c -m 644 Makefile copy2 > > >> install -c -m 644 Makefile copy3 > > >> install -c -m 644

Re: "make -jN" requires mechanical changes to a Makefile

On Mon, 13 May 2019 00:05:59 +0200 Bruno Haible wrote: > Howard Chu wrote: > > >> Example with one rule creating 4 files: > > >> > > >> all : copy1 > > >> > > >> copy1: Makefile > > >> install -c -m 644 Makefile copy1 > > >> install -c -m 644 Makefile copy2 > > >> install

Re: "make -jN" requires mechanical changes to a Makefile

Howard Chu wrote: > >> Example with one rule creating 4 files: > >> > >> all : copy1 > >> > >> copy1: Makefile > >> install -c -m 644 Makefile copy1 > >> install -c -m 644 Makefile copy2 > >> install -c -m 644 Makefile copy3 > >> install -c -m 644 Makefile copy4 > >

Re: "make -jN" requires mechanical changes to a Makefile

Bruno Haible wrote: > Henrik Carlqvist wrote: >> Example with one rule creating 4 files: >> >> all : copy1 >> >> copy1: Makefile >> install -c -m 644 Makefile copy1 >> install -c -m 644 Makefile copy2 >> install -c -m 644 Makefile copy3 >> install -c -m 644 Makefile

Re: "make -jN" requires mechanical changes to a Makefile

Henrik Carlqvist wrote: > Example with one rule creating 4 files: > > all : copy1 > > copy1: Makefile > install -c -m 644 Makefile copy1 > install -c -m 644 Makefile copy2 > install -c -m 644 Makefile copy3 > install -c -m 644 Makefile copy4 I think the "represen

Re: "make -jN" requires mechanical changes to a Makefile

On Sun, 12 May 2019 22:23:12 +0200 Bruno Haible wrote: > Now, when my use-case is: > - one rule that produces N files (N > 1), > - I want "make" to execute the rule only once, not N times, > even with parallel make. > What is the solution? I think that the only good solution is to make su

Re: "make -jN" requires mechanical changes to a Makefile

Hi Paul, > > The real workaround goes like this: > > > > === > > all : copy1 copy2 copy3 copy4 > > > > copy1: Makefile > > install -c -m 644 Makefile copy1 > > install -c -m 644 Makefile copy2 > > install -c -m 644 Makefile

Re: "make -jN" requires mechanical changes to a Makefile

On Sun, 2019-05-12 at 18:07 +0200, Bruno Haible wrote: > This workaround doesn't actually work (in the actual case of GNU gettext): > it fails the "make distcheck" verification. > > The real workaround goes like this: > > === > all : copy1 copy2 cop

Re: "make -jN" requires mechanical changes to a Makefile

Hi, I wrote: > The workaround is to introduce an intermediate target: > > === > all : copy1 copy2 copy3 copy4 > > copy1 copy2 copy3 copy4: install-copies > .PHONY: install-copies > install-copies: Makefile > install -c -m 644 Makefile copy1 >

Re: "make -jN" requires mechanical changes to a Makefile

Henrik Carlqvist wrote: > If you really prefer to write rules which generates more than one target > the "right" way to avoid parallel make would be to add the .NOTPARALLEL > target in the Makefile. This way allows to turn off parallel make for a single Makefile. Indeed, this might be a better com

Re: "make -jN" requires mechanical changes to a Makefile

> In the current state, supporting parallel make requires extra work > for the maintainer. > > Or would you recommend that I add this snippet to the top-level > Makefile of all my projects? > > # This package does not support parallel make. > # So, turn off parallel execution (at least in GNU mak

Re: "make -jN" requires mechanical changes to a Makefile

Hi Paul, > This makefile should be written correctly, as: > > all : copy1 copy2 copy3 copy4 > > copy1: Makefile > install -c -m 644 Makefile copy1 > copy2: Makefile > install -c -m 644 Makefile copy2 > copy3: Makefile > install -c -m 644 Makefile copy3 > c

Re: "make -jN" requires mechanical changes to a Makefile

On Fri, 2019-05-10 at 22:49 +0200, Bruno Haible wrote: > But supporting parallel requires, in some cases, mechanical changes to a > Makefile. How about if GNU make was improved to not require me to make these > changes? > > Namely, consider this Makefile: >

Re: Make in Windows10

Please choose just one GNU make mailing list to ask questions on: it gets confusing if multiple lists are involved. On Mon, 2017-06-05 at 11:08 +, Ramya S Ganesh (RBEI/ETC5) wrote: > We tried executing make scripts using 4.1 version of make in Windows > 7 PC and it took a reasonable amount of

Re: make -n fails if export is used with recursion

On Sun, 2017-05-28 at 10:40 +1000, Robert Durkacz wrote: > So I am suggesting that if we must have "export" in make, then the > workings of "make -n" should be upgraded to report any exports that > are set up. "make -n" is primarily an interactive debugging/informational tool letting the user know

RE: Make all throws alot of errors

Those errors aren't indicative of a bug in make, so I've bcc:d the bug-make list. Well done for quoting what you typed and the first error from the computer, but sadly things had already gone wrong before that point, perhaps during an earlier "configure" stage. Perhaps the error there wasn't p

Re: Make, MAKE_TERMOUT, color escape sequences, TTYs, and PTYs

On the one hand I can see some value in this effort, but it seems simpler for build maintainers to overtly request colorized output if that's what they want. If the tools start generating escape sequences for other than colorizing text it may not be sufficient, but in general it seems like a bette

Re: Make, MAKE_TERMOUT, color escape sequences, TTYs, and PTYs

On Tue, 2016-05-31 at 15:06 -0700, Josh Triplett wrote: > However, if programs start observing those variables, that seems > highly likely to lead to potential breakage in makefiles, for one key > reason: those variables remain in the environment even for programs > run with stdout/stderr redirecte

Re: Make, MAKE_TERMOUT, color escape sequences, TTYs, and PTYs

On Sun, May 29, 2016 at 11:04:49AM -0400, Paul Smith wrote: > On Sat, 2016-05-28 at 16:09 -0700, Josh Triplett wrote: > > If make's own stdout/stderr refers to a PTY, make could create PTYs in > > place of pipes, collect output that way, and synchronize it to its own > > stdout/stderr as it does no

Re: Make, MAKE_TERMOUT, color escape sequences, TTYs, and PTYs

Hi, I can imagine this will be difficult to make complete, useful and bug free, there are many issues that will appear. I'd suggest saving a lot of time in development while still allowing the feature in its earliest forms and leaving room for issues to be resolved at will by providing hooks for

Re: Make, MAKE_TERMOUT, color escape sequences, TTYs, and PTYs

On Sat, 2016-05-28 at 16:09 -0700, Josh Triplett wrote: > If make's own stdout/stderr refers to a PTY, make could create PTYs in > place of pipes, collect output that way, and synchronize it to its own > stdout/stderr as it does now. Just for clarity: GNU make doesn't use pipes to collect output,

Re: make ignore -std=c++11

On Mon, 2016-05-09 at 23:52 +0800, Jesse wrote: > I wrote a c++ program which contains "auto". > And I've wrote the makefile: g++ -std=c++11 ... > However, it still remind of "..does not name a type ..." > I've searched on the net for solution but gain nothing. > I think it might be a bug in m

Re: Make regression in 4.0-8.1 (from Debian stable)

On Thu, 2015-11-26 at 10:02 +0530, Jay Aurabind wrote: > Make 3.81 will finish the build in 27 minutes. With the same > conditions for make 4, it takes 1 hour. Most likely it's this bug: https://savannah.gnu.org/bugs/index.php?44555 ___ Bug-make mailin

Re: Make page error.

On Mon, 2015-11-02 at 10:14 -0500, Varun H wrote: > Typo: "an object file, the linker to produce an executable, ar to > update a library, or TeX or Makeinfo to format..." > I believe "or" is misspelled as "ar". Actually "ar" is intended here. "ar" is a program on UNIX systems. It's short for "arc

  1   2   3   4   5   6   7   >