[bug #66658] GNU make should show features with --version

Follow-up Comment #2, bug #66658 (group make): For the short term you can use: echo '$(info $(.FEATURES))' | make -f- 2>/dev/null (the redirect is to avoid the "make: *** No targets. Stop" message. ___ Reply to this item at:

[bug #66658] GNU make should show features with --version

Follow-up Comment #1, bug #66658 (group make): Suggestion is by Basile Starynkevitch (France) working on https://github.com/RefPerSys/RefPerSys/ (GPLv3 inference engine for Linux) ___ Reply to this item at:

[bug #66658] GNU make should show features with --version

URL: <https://savannah.gnu.org/bugs/?66658> Summary: GNU make should show features with --version Group: make Submitter: None Submitted: Mon 13 Jan 2025 11:05:11 AM UTC Severity: 3 - Normal

Re: Bug in GNU make if -j used with very high values

On Wed, 2024-12-18 at 15:29 -0500, Dianne Skoll wrote: > On Debian GNU/Linux 12 with default settings, the command: > >    make -j 7 > > hangs. This is https://savannah.gnu.org/bugs/index.php?66499

Bug in GNU make if -j used with very high values

Hi, On Debian GNU/Linux 12 with default settings, the command: make -j 7 hangs. That's because make tries to fill a pipe with 70,000 '+' characters to act as a counting semaphore to limit the number of spawned processes, but the default capacity of a pipe is 64K. I recommend initially o

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

Update of bug #65972 (group make): Status:None => Not A Bug Open/Closed:Open => Closed Operating System: POSIX-Based => Any ___

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

Follow-up Comment #6, bug #65972 (group make): I'm fine with closing this bug, but I don't know how to do it. ___ Reply to this item at: ___ Message sen

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

Follow-up Comment #5, bug #65972 (group make): This seems to do the trick: .SECONDARY: $(OBJS) $(foreach T,$(TESTS),$($T-test_OBJDEPS)) $(HELPERS:%=%.wrap) So your suggestion covered it by ~80%. Thanks! ___ Reply to this item at:

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

Follow-up Comment #4, bug #65972 (group make): I don't think we will allow "going back" to the old behavior. That behavior was just a bug (IMO) and also, your makefile is fragile by relying on it (if that object file was ever mentioned anywhere else outside of a pattern rule, it would break). If

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

Follow-up Comment #3, bug #65972 (group make): Thanks for your response. I only saw it after adding my last comment. > .SECONDARY: $(OBJS) $(foreach T,$(TESTS),$($T-test_OBJDEPS)) That doesn't do the trick, but it seems to go into the right direction. I'll keep experimenting. _

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

Follow-up Comment #2, bug #65972 (group make): I bisected this manually to 510e5ce ("[SV 60188] Explicit prereqs cannot be intermediate files"). So apparently this change was made deliberately in the context of bug #60188. I wish it was possible to restore the historical behavior. I wonder if I

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

e important difference is actually this line: Prerequisite '../libmultipath/devmapper.o' is newer than target 'dmevents-test'. Once this prerequisite is decided to be rebuilt, then all the other prerequisites, which were considered intermediate due to the .SECONDARY stateme

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

Additional Item Attachment, bug #65972 (group make): File name: sid.logSize: 356KiB File name: f40.logSize: 597KiB AG

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

URL: <https://savannah.gnu.org/bugs/?65972> Summary: Change in dependency treatment between GNU make 4.3 and 4.4.1 Group: make Submitter: mwilck Submitted: Wed 10 Jul 2024 02:59:38 PM UTC Severity: 3 -

Re: inconsistent use of CFLAGS in the GNU make manual

s not used, as Automake adds $(CFLAGS) for linking), like -pg, > > -pthread, and sanitizer options. > > I'm not sure where such advice would appear; it's not really the > intention of the GNU Make manual to describe the ins and outs of how to > invoke a compiler (n

Re: inconsistent use of CFLAGS in the GNU make manual

ing), like -pg, > -pthread, and sanitizer options. I'm not sure where such advice would appear; it's not really the intention of the GNU Make manual to describe the ins and outs of how to invoke a compiler (notwithstanding all compilers are different). The manual documents: CFLAGS

inconsistent use of CFLAGS in the GNU make manual

In the GNU make manual 0.77 as found at https://www.gnu.org/software/make/manual/make.html the implicit rule for linking is, as given in Section 10.2: n is made automatically from n.o by running the C compiler to link the program. The precise recipe used is ‘$(CC) $(LDFLAGS) n.o

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

On 4/19/24 15:15, Paul Smith wrote: On Fri, 2024-04-19 at 14:38 -0400, Dmitry Goncharov wrote: On Fri, Apr 19, 2024 at 1:42 PM Paul Smith wrote: The main advantages to alloca are twofold: 1) efficiency for small local buffers, which GNU Make uses a lot. 2) simplification of the code because

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

On Fri, 2024-04-19 at 14:38 -0400, Dmitry Goncharov wrote: > On Fri, Apr 19, 2024 at 1:42 PM Paul Smith wrote: > > The main advantages to alloca are twofold: > > > > 1) efficiency for small local buffers, which GNU Make uses a lot. > > > > 2) simplification of t

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

On 4/19/24 14:38, Dmitry Goncharov wrote: On Fri, Apr 19, 2024 at 1:42 PM Paul Smith wrote: The main advantages to alloca are twofold: 1) efficiency for small local buffers, which GNU Make uses a lot. 2) simplification of the code because you don't have to track this memory and ensure

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

On Fri, Apr 19, 2024 at 1:42 PM Paul Smith wrote: > The main advantages to alloca are twofold: > > 1) efficiency for small local buffers, which GNU Make uses a lot. > > 2) simplification of the code because you don't have to track this > memory and ensure it's freed re

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

On Fri, 2024-04-19 at 13:15 -0400, Dennis Clarke wrote: > Yep. The calls to alloca() seem to be all over the place in the code > base and I can not figure out why anyone would want a non-portable > and non-standard thing like that but here we are. alloca() has been used in the GNU Make

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

On 4/19/24 10:27, Paul Smith wrote: On Fri, 2024-04-19 at 09:54 -0400, Dennis Clarke via Bug reports and discussion for GNU make wrote: Where does one even begin to discover where something ( everything? ) went so horribly wrong? The very first thing you should try is re-configuring GNU Make

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

On Fri, 2024-04-19 at 09:54 -0400, Dennis Clarke via Bug reports and discussion for GNU make wrote: > Where does one even begin to discover where something ( everything? ) > went so horribly wrong? The very first thing you should try is re-configuring GNU Make without any special flags

[bug #64964] GNU Make deletes intermediate targets that are pattern-rule dependancies

Update of bug #64964 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: As Dmitry says this is

[bug #64964] GNU Make deletes intermediate targets that are pattern-rule dependancies

Follow-up Comment #1, bug #64964 (project make): The rules in this example 'foo%: foo%.txt' and 'foo%.txt: foo%.sh' are implicit. Implicit rules can be specified in the makefile. Make's behavior is correct. ___ Reply to this item at:

[bug #64964] GNU Make deletes intermediate targets that are pattern-rule dependancies

URL: <https://savannah.gnu.org/bugs/?64964> Summary: GNU Make deletes intermediate targets that are pattern-rule dependancies Group: make Submitter: pablorackham Submitted: sam. 02 déc. 2023 16:42:27 Sever

Re: GNU make troubleshooting

On Sun, 2023-09-03 at 02:24 +0200, Alejandro Colomar wrote: > Let's add one more: > > -  Make has problems running the SHELL This is an interesting situation but I don't think it belongs in the GNU make manual. -- Paul D. Smith Find some GNU make tips at:

Re: GNU make troubleshooting

Hi Paul, On 2023-08-26 18:48, Paul Smith wrote: > I added a new appendix to the GNU make manual for troubleshooting help; > I haven't pushed it yet. See below. Comments welcome. > > I think the outline you provided earlier, Bruno, has the problem that a > lot of i

Re: GNU make troubleshooting

he old "Ask Mr Make" columns by John Graham-Cumming > > - You may not want to get into listing third-party tools I don't think I want to put things of that level to the manual. But, maybe there's another good place to collect things like that. -- Paul D. Smith

Re: GNU make troubleshooting

dro Colomar wrote: > >> In fact, I'm going to define .SILENT always in the Linux man-pages, > >> since V=1 is just an unnecessary duplicate for --degub=print. > >> I'll make V=1 only have the effect of redirecting stderr of certain > >> programs. > > > &

Re: GNU make troubleshooting

ake V=1 only have the effect of redirecting stderr of certain >> programs. > > Just be aware that --debug=print is a new feature as of GNU Make 4.4. Hmm. > > You shouldn't rely on users having access to it, unless you're willing > to recommend that version (or higher). We

Re: GNU make troubleshooting

s. Just be aware that --debug=print is a new feature as of GNU Make 4.4. You shouldn't rely on users having access to it, unless you're willing to recommend that version (or higher). I reminded myself that the --trace option is a shortcut for --debug=print,why and so I will rework all

Re: GNU make troubleshooting

x27;s not a valid POSIX error code. It's true that "2" is the exit code for a shell if it fails to parse the shell script due to a syntax error or something; maybe that's worth mentioning. -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org

Re: GNU make troubleshooting

On 2023-08-27 15:35, Alejandro Colomar wrote: > On 2023-08-27 15:33, Paul Smith wrote: >> On Sun, 2023-08-27 at 09:26 -0400, Paul Smith wrote: >>> Yes, that's a good idea to mention .SILENT. >> >> Actually I think I will simply recomment using --debug=print instead as >> that's simpler. > > LGTM.

Re: GNU make troubleshooting

On 2023-08-27 15:33, Paul Smith wrote: > On Sun, 2023-08-27 at 09:26 -0400, Paul Smith wrote: >> Yes, that's a good idea to mention .SILENT. > > Actually I think I will simply recomment using --debug=print instead as > that's simpler. LGTM. That's much better, as you don't modify the Makefile, a

Re: GNU make troubleshooting

"V=1" enables "extra" > debugging: normally it just disables "@". I would prefer to avoid > adding descriptions that depend on how specific makefiles are > implemented, unless that is also described in the GNU Make manual. The V=1 stuff is nowadays standard in the GNU project's makefiles, so I think it would be a good addition. Of course, it's your call.

Re: GNU make troubleshooting

On Sun, 2023-08-27 at 09:26 -0400, Paul Smith wrote: > Yes, that's a good idea to mention .SILENT. Actually I think I will simply recomment using --debug=print instead as that's simpler. -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org

Re: GNU make troubleshooting

variables to set. -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

Re: GNU make troubleshooting

tion that. > > What does "V=1" do, that removing the "@" doesn't do? I'm not familiar > with any makefile where "V=1" enables "extra" debugging: normally it > just disables "@". I would prefer to avoid adding descriptions that

Re: GNU make troubleshooting

uot; do, that removing the "@" doesn't do? I'm not familiar with any makefile where "V=1" enables "extra" debugging: normally it just disables "@". I would prefer to avoid adding descriptions that depend on how specific makefiles are implement

Re: GNU make troubleshooting

Hi Paul, On 2023-08-26 18:48, Paul Smith wrote: > I added a new appendix to the GNU make manual for troubleshooting help; > I haven't pushed it yet. See below. Comments welcome. > > I think the outline you provided earlier, Bruno, has the problem that a > lot of i

Re: GNU make troubleshooting

> From: Paul Smith > Date: Sat, 26 Aug 2023 12:48:05 -0400 > > I added a new appendix to the GNU make manual for troubleshooting help; > I haven't pushed it yet. See below. Comments welcome. Thanks, this sounds very useful. Some comments below. >If you have proble

Re: GNU make troubleshooting

I added a new appendix to the GNU make manual for troubleshooting help; I haven't pushed it yet. See below. Comments welcome. I think the outline you provided earlier, Bruno, has the problem that a lot of it isn't really about troubleshooting per se, it's about how to write makef

[bug #64591] SBOM-friendly CMake-like File API for GNU Make

URL: <https://savannah.gnu.org/bugs/?64591> Summary: SBOM-friendly CMake-like File API for GNU Make Group: make Submitter: edelsohn Submitted: Thu 24 Aug 2023 05:11:49 PM UTC Severity: 3 -

Re: wildcard and globstar (was: GNU make troubleshooting)

On Sun, Jul 16, 2023 at 4:59 PM Alejandro Colomar wrote: > I'm still interested in globstar support, though. It would make that > line shorter and more robust. Maybe you could add an option > --glob=globstar or similar to enable support. gmake does not keep its own impl of glob. It uses a copy

Re: GNU make troubleshooting

Dmitry Goncharov wrote: > > I believe these two user goals are so different; they belong in different > > chapters. > ... > In other words, i don't see a chapter on how to avoid big debug output > without optimizing the makefile. Wait a second. "How to avoid big debug output?" is not one of the pr

Re: GNU make troubleshooting

On Sat, 2023-07-15 at 11:28 -0400, Dmitry Goncharov wrote: > Appendix A Debug Output. Thanks for this Dmitry; I spent some time this weekend working on a new section of the manual that would overlap with this. However I will definitely examine your patch and make sure the points you (and everyone

Re: GNU make troubleshooting

On 2023-07-16 22:14, Philip Guenther wrote: > I just put this at the very end of top makefile: > > ${MAKEFILE_LIST}: ; Hmm, that's giving me another good idea. Luckily, I haven't pushed the changes I had done yet. Thanks! Alex > > Philip Guenther -- GPG ke

Re: wildcard and globstar (was: GNU make troubleshooting)

Hi! On 2023-07-16 18:31, Dmitry Goncharov wrote: > On Sun, Jul 16, 2023 at 10:49 AM Alejandro Colomar wrote: >> I guess I'd need some kind of globstar support in GNU Make to be able >> to use that > > Do you mean you need to find .mk files in subdirectories at diff

Re: GNU make troubleshooting

I just put this at the very end of top makefile: ${MAKEFILE_LIST}: ; Philip Guenther On Sun, Jul 16, 2023 at 12:25 PM Torbjorn SVENSSON < torbjorn.svens...@foss.st.com> wrote: > > > On 2023-07-16 15:58, Alejandro Colomar wrote: > > Wow! That's a great help for debugging the Linux man-pages's m

Re: GNU make troubleshooting

On 2023-07-16 15:58, Alejandro Colomar wrote: Wow! That's a great help for debugging the Linux man-pages's makefiles, which don't need to be remade. It was very painful to me to ignore so much make -d output. I applied the following patch, and it works like a charm.

Re: wildcard and globstar (was: GNU make troubleshooting)

On Sun, Jul 16, 2023 at 10:49 AM Alejandro Colomar wrote: > I guess I'd need some kind of globstar support in GNU Make to be able > to use that Do you mean you need to find .mk files in subdirectories at different depth levels? mk:=$(wildcard */*/*.mk */*.mk *.mk) regards, Dmitry

wildcard and globstar (was: GNU make troubleshooting)

es/man-pages.git/commit/?id=c98d237c22e9e898ae7d05ee7eac47791bd3> > > Glad you liked it. :-) > Rather than `find -type f...` (which is painfully slow) why don't you > do something like > mk:=$(wildcard $(MAKEFILEDIR)/*.mk) > ? I guess I'd need some kind of globstar support in GNU Make to

Re: GNU make troubleshooting

Como estas, Alex? On Sun, Jul 16, 2023 at 9:59 AM Alejandro Colomar wrote: > I applied the following patch > Glad you liked it. Rather than `find -type f...` (which is painfully slo

Re: GNU make troubleshooting

Hi Dmitry! On 2023-07-15 17:28, Dmitry Goncharov wrote: [...] > > $ make -d |tail +7 |head > Reading makefiles... > Reading makefile 'makefile'... > Updating makefiles > Considering target file 'makefile'. > Looking for an implicit rule for 'makefile'. >Trying pattern rule '%: %.o' wi

Re: GNU make troubleshooting

On Sat, Jul 15, 2023 at 5:27 PM Bruno Haible wrote: > I believe these two user goals are so different; they belong in different > chapters. i believe, a good approach to big debug output is to modify the makefile to relieve make from doing redundant work. Once make only does necessary minimal work

Re: GNU make troubleshooting

Minor side point: the "tail +7" option is deprecated by POSIX, replaced by "tail -n+7". Official GNU documentation should preferably follow POSIX. David On Sat, Jul 15, 2023 at 5:27 PM Bruno Haible wrote: > Dmitry Goncharov wrote: > > > 1) The title, and what does the user want? > > This patch

Re: GNU make troubleshooting

Dmitry Goncharov wrote: > > 1) The title, and what does the user want? > This patch is not a full-fledged troubleshooting guide. ... > > Is that really what I want to do and should do, as a user? > i believe, makefile authors should apply these techniques. OK, then it's appropriate to create *thre

Re: GNU make troubleshooting

> 1) The title, and what does the user want? i guess, users want make to do the minimal amount of work required to fulfil its duties correctly (e.g. track all dependencies, rebuilds, etc). This patch is not a full-fledged troubleshooting guide. This patch describes how to minimize the work that mak

Re: GNU make troubleshooting

Hello Dmitry, Dmitry Goncharov wrote: > >I tried -d a couple of times, and it produced a ton of output, that > >was too much for me to make sense of. Probably 10% to 20% of the > >developers in general have trace filtering skills, that is, know how > >to extract the essential infor

Re: GNU make troubleshooting

ere are simple techniques that we can utilize to simplify this output and extract useful information out of it. Let us see what this output contains. $ make -d |head GNU Make 4.4.90 Built for x86_64-pc-linux-gnu Copyright (C) 1988-2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL

Re: GNU make troubleshooting

p maintain. No info on the > evaluations shown above, which would be useful to me. There is lots > of information that looks like it would be useful to a GNU Make > maintainer. No. The -d and --trace options are for users who want to understand why make is choosing a certain rule, why a given

Re: GNU make troubleshooting

make computed as the >> final value for each of these variables, and also what linenumber of >> the makefile was used to set the final version: >> >> # makefile (from 'Makefile', line 12) >> GCC_COMPILER := 0 >>... >> # makefile (from &#

Re: GNU make troubleshooting

w you what make computed as the > final value for each of these variables, and also what linenumber of > the makefile was used to set the final version: > > # makefile (from 'Makefile', line 12) > GCC_COMPILER := 0 >... > # makefile (from 'Makefile'

Re: GNU make troubleshooting

mber of the makefile was used to set the final version: # makefile (from 'Makefile', line 12) GCC_COMPILER := 0 ... # makefile (from 'Makefile', line 1) GREP = grep ... I don't want to suggest that everything is just peachy. There are lots of rough edge

Re: GNU make troubleshooting

> From: Bruno Haible > Date: Mon, 10 Jul 2023 21:41:24 +0200 > > Paul Smith wrote: > > Showing the "macroexpanded make sources" is difficult because make > > doesn't just expand an entire line then parse it. Makefile syntax is > > context-sensitive so you can't know how or if to expand parts of

Re: GNU make troubleshooting

> From: Jeffrey Walton > Date: Mon, 10 Jul 2023 16:34:49 -0400 > Cc: bug-make@gnu.org > > I would add GNU's make lacks minimal debug facilities. I think "make -p" and "make -d" do provide ample debugging capabilities. > I think trace is worthless. It does not help the folks writing > makefiles.

Re: GNU make troubleshooting

On Mon, Jul 10, 2023 at 4:45 PM Paul Smith wrote: > > [...] > > That's like peppering a program with printf's. I would like to > > understand why a statement was (or was not) evaluated, and if > > evaluated the result, but there is no option with the effect of > > Bash's 'set +x'. > > I think I do

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 16:34 -0400, Jeffrey Walton wrote: > I would add GNU's make lacks minimal debug facilities. I assume this is what Bruno means by his point #3: "Single-stepping or tracing function execution". > That's like peppering a program with printf's. I would like to > understand why a

Re: GNU make troubleshooting

Alejandro Colomar wrote: > In GNU Make, the "printf" statement is the > $(info ...) function. Maybe you didn't know about it? Correct, I did not know about it. I created a 'dummy' target with an echo command... It would be really useful to collect all these vari

Re: GNU make troubleshooting

On Mon, Jul 10, 2023 at 2:32 PM Bruno Haible wrote: > > In recent build system discussions on gnu-prog-discuss, the suggestion was > made [1] to use GNU make's power instead of autoconf, automake, and POSIX > make. > > I think GNU make is lacking transparency / debugga

Re: GNU make troubleshooting

a line until you've already expanded other parts. Of course make could keep track of this for generating this kind of output. If no perfect solution to this problem is possible, how about implementing a simple approximation first, and then improve it based on user feedback? Because how is

Re: GNU make troubleshooting

Paul Smith wrote: > > I get the same output with GNU make 4.4 as with 4.3. > > Apologies for my mistake: I'm using the latest release (4.4.1). > I tried your test: > > $ make --trace mbrtoc32.o > Makefile:1752: update target 'mbrtoc32.o' due to: target

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 21:41 +0200, Bruno Haible wrote: > > I'm not interested in implementing an "interactive" mode for > > single-stepping GNU Make.  Maybe someone else wants to do it but my > > suspicion is that the code changes needed would be massively > &

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 21:47 +0200, Bruno Haible wrote: > Paul Smith wrote: > > Maybe a version difference.  I'm using 4.4. > > I get the same output with GNU make 4.4 as with 4.3. Apologies for my mistake: I'm using the latest release (4.4.1). I tried your test:

Re: GNU make troubleshooting

Paul Smith wrote: > Maybe a version difference. I'm using 4.4. I get the same output with GNU make 4.4 as with 4.3. Bruno

Re: GNU make troubleshooting

expanded other parts. Of course make could keep > track of this for generating this kind of output. If no perfect solution to this problem is possible, how about implementing a simple approximation first, and then improve it based on user feedback? Because how is a GNU make user supposed to un

Re: GNU make troubleshooting

t;It's not acceptable (to me) to only show the one newest > file", and I say "A tool that shows me 3.7 KB worth of file names in > one line is useless to me, because that is information overload, and > I don't have good filtering skills". I think your problems with

Re: GNU make troubleshooting

e:1: update target 'all' due to: target does not exist echo hi; touch all hi > I'm using GNU make 4.3. Maybe a version difference. I'm using 4.4.

Re: GNU make troubleshooting

Paul Smith wrote: > It's not acceptable (to me) to only show the one newest file, not all > files that are newer than the target, because often you want to know > all the newer files. You say "It's not acceptable (to me) to only show the one newest file", and I say "A tool that shows me 3.7 KB wor

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 20:46 +0200, Bruno Haible wrote: > The " due to: " is useless, since these files > have not changed since the last compilation. (Suggestion: Reduce this > list by showing only the file with the newest timestamp. Files with > older timestamps are redundant.) I can't explain wh

Re: GNU make troubleshooting

echo hi hi > 3) Single-stepping or tracing function execution. Tracing is possible although if we just enable tracing for all variable expansion you'll get a TON of output. Maybe the user could ask to trace expansion of certain things only. I'm not interested in implementing an &

Re: GNU make troubleshooting

> 2) Where is the Makefile source for each command that gets executed? >For each command that gets executed, print not only the command (or >nothing if the line begins with '@'), but also the location (which >Makefile, which line number). > >This would help in a number of situation

GNU make troubleshooting

Hi all, In recent build system discussions on gnu-prog-discuss, the suggestion was made [1] to use GNU make's power instead of autoconf, automake, and POSIX make. I think GNU make is lacking transparency / debuggability / serviceability features before this suggestion makes sense. Especiall

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

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

Hi, 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? Cheers, Alex -- GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5 makeerror-4.4.1-x86_64-pc-linux-gnu-t3wj.tar.gz Descript

GNU Make 4.4.1 released!

GNU make is a tool which controls the generation of executables and other non-source files of a program from the program's source files. You can learn more at: https://www.gnu.org/software

Re: GNU Make 4.4.0.91 on Cygwin

> 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) usi

Re: GNU Make 4.4.0.91 on Cygwin

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

> 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: > https://savannah.gnu.

Re: GNU Make 4.4.0.91 on Cygwin

On Sun, 2023-02-19 at 17:20 -0500, Ken Brown wrote: > > Hm.  This is a test of this: > > https://savannah.gnu.org/bugs/index.php?57674 > > > > which explicitly removes PATH from the environment completely.  It > > should use a default PATH, which should mean "echo" works even so.  > > I'm not real

Re: GNU Make 4.4.0.91 on openSUSE Leap 15.2

On Sun, 2023-02-19 at 22:15 +0100, Bruno Haible wrote: > gnulib/m4/glob.m4 contains a test for this bug: Thanks! I adapted this for GNU make and hopefully it will correctly detect this issue. # Check the system to see if it provides GNU glob. If not, use our # local version. Also av

Re: GNU Make 4.4.0.91 on Cygwin

On 2/19/2023 2:59 PM, Paul Smith wrote: 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: https://savannah.gnu.org/bugs/index.php?57674 which exp

  1   2   3   4   5   6   7   8   9   10   >