[bug #67195] surprising behavior with prerequisite search via vpath

Follow-up Comment #4, bug #67195 (group make): The patch in the attachments adds logging of directory search. $ ~/src/gmake/make/l64/make --debug=s -R Directory searching for 'all'. 'all' not found by directory search. Directory searching for '../include/file.x'. '../include/file.x' matches

[bug #67195] surprising behavior with prerequisite search via vpath

Additional Item Attachment, bug #67195 (group make): File name: sv67195_vpath_logging.diff Size: 19KiB AGPL NOTICE These attachments are served by Savane. You can download the corresponding source code of Sav

[bug #67195] surprising behavior with prerequisite search via vpath

Follow-up Comment #3, bug #67195 (group make): > Furthermore, if we remove (or ignore) the 'all' target and directly specify > '../include/file.x' as a goal: > >> make ../include/file.x > > then this results in: > > make: '../lib/include/../include/file.x' is up to date. > > This demonstrates

[bug #67195] surprising behavior with prerequisite search via vpath

Follow-up Comment #1, bug #67195 (group make): 'all' depends on prerequisite '../include/file.x'. Make performs directory search for prerequisite '../include/file.x'. Prerequisite '../include/file.x' matches directory search pattern '%.x'. Make discovers that there is '../include/file.x' in direct

Re: seg fault with EXTRA_PREREQS

On Tue, Apr 22, 2025 at 8:54 PM Shim Manning wrote: > > Minimal test. Generates a list of 1000 prerequisites. > > list := $(shell for n in $$(seq 1 1000); do echo file_$$n; done) > all: .EXTRA_PREREQS := $(list) > all: > echo "fin" > > And tes making a copy of the table appears to fix it Thank y

[bug #67046] .EXTRA_PREREQS causes a segfault.

Additional Item Attachment, bug #67046 (group make): File name: sv67046.diff Size: 3KiB AGPL NOTICE These attachments are served by Savane. You can download the corresponding source code of Savane at https

[bug #67046] .EXTRA_PREREQS causes a segfault.

Follow-up Comment #1, bug #67046 (group make): A user reported a crash caused by .EXTRA_PREREQS carrying a large number of prerequisites. The original bug report is here https://lists.gnu.org/archive/html/bug-make/2025-04/msg9.html. $ ls makefile $ cat makefile list := $(shell for n in $$(s

[bug #67046] .EXTRA_PREREQS causes a segfault.

: None ___ Follow-up Comments: --- Date: Wed 23 Apr 2025 02:36:53 AM GMT By: Dmitry Goncharov . ___ Reply to this item at:

Re: seg fault with EXTRA_PREREQS

On Fri, Apr 18, 2025 at 11:12 PM Shim Manning wrote: > > Seems that using .EXTRA_PREREQS can cause a segfault under the right > conditions. ... > snap_deps > hash_map_arg (loop happens here) > snap_file > expand_extra_prereqs > enter_file > hash_insert_at > hash_rehash (loop no longer valid) >

Re: order-only prerequisites themselves get rebuilt when not needed

On Tue, Mar 18, 2025 at 8:06 AM Paul Smith wrote: > I see from the patch: you don't mean "never" you mean, only if the > prerequisite does not exist will it be updated. Right. > I agree this preserves probably the most common reason for using OO > prereqs (to create directories) This preserves

Re: order-only prerequisites themselves get rebuilt when not needed

On Mon, Mar 17, 2025 at 8:12 AM Paul Smith wrote: > The question we have think carefully about is what sort of backward- > compatibility issues, if any, we could introduce. Are there situations > where people are relying on the current behavior? It is possible that someone relies that running 'm

[bug #66915] Avoid rebuilding existing order-only prerequisites.

Status: None ___ Follow-up Comments: --- Date: Sat 15 Mar 2025 12:18:34 PM UTC By: Dmitry Goncharov . ___ Reply to this i

Re: order-only prerequisites themselves get rebuilt when not needed

On Mon, Mar 10, 2025 at 8:12 AM Paul Smith wrote: > > On Sat, 2025-03-08 at 11:34 -0900, Britton Kerin wrote: > > What confuses me is that since the explicitly requested foo exists > > and isn't out of date with respect to any non-order-only prereqs (in > > the example it doesn't have any) and the

[bug #66915] Avoid rebuilding existing order-only prerequisites.

Additional Item Attachment, bug #66915 (group make): File name: sv66915.diff Size: 5KiB AGPL NOTICE These attachments are served by Savane. You can download the corresponding source code of Savane at https

[bug #66915] Avoid rebuilding existing order-only prerequisites.

Follow-up Comment #1, bug #66915 (group make): Suggested by Britton Kerin here https://lists.gnu.org/archive/html/bug-make/2025-03/msg6.html. This is an excerpt from that email. "What confuses me is that since the explicitly requested foo exists and isn't out of date with respect to any non-or

[bug #66870] memory corruption

Follow-up Comment #2, bug #66870 (group make): There is a buffer overflow when shellflags contains characters special to shell, like =. See https://savannah.gnu.org/bugs/?65588. ___ Reply to this item at:

[bug #66500] Caching of timestamps prevents proper builds

Follow-up Comment #5, bug #66500 (group make): The rule for foo/tar is lacking a recipie. In this case make has no reason to invalidate the cached mtime of foo/tar. As explained earlier make has no idea that the recipie for foo touched foo/tar. Any recipie for foo/tar, even a empty one, is suffici

[bug #66500] Caching of timestamps prevents proper builds

Follow-up Comment #3, bug #66500 (group make): This statement applies as make is traversing the graph and is considering a target. When make is considering baz foo/tar exists and is older. This is the typical issue when a recipie builds something other than $@. _

[bug #66237] Grouped target dependencies don't function properly in dry-run mode

Follow-up Comment #1, bug #66237 (group make): I can reproduce this with make-4.3, however, the latest make build from master behaves correctly here. $ make --version GNU Make 4.4.90 Built for x86_64-pc-linux-gnu Copyright (C) 1988-2024 Free Software Foundation, Inc. License GPLv3+: GNU GPL versio

[bug #66500] Caching of timestamps prevents proper builds

Follow-up Comment #1, bug #66500 (group make): There is this makefile in the attachment. baz: foo/tar touch baz foo/tar: foo foo: bar -mkdir foo touch foo/tar Make is correct. Make is doing what this makefile tells make to do. The user touches bar and runs make. Make goes through

Re: The first word in $(MAKEFLAGS) is not a group of short options

On Sun, Feb 9, 2025 at 12:04 PM Masahiro Yamada wrote: ... > This is no longer true when MAKEFLAGS is set > via the command line. A command line definition of MAKEFLAGS is a bad idea. https://savannah.gnu.org/bugs/?62469 regards, Dmitry

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #10, bug #66499 (group make): Sounds like you had to do some investigation. Thank you for your report. ___ Reply to this item at: ___

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #8, bug #66499 (group make): Thanks for review, Paul. Heiko, do you mind sharing the scenario that causes you to specify such high value of jobs? ___ Reply to this item at:

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #5, bug #66499 (group make): Tested on sun 64 and 32 bits and linux 64 and 32 bits. Here is an example $ ls makefile $ cat makefile all:; $(info hello, world) $ make -j68 make: warning: number of jobs is limited to 16384 hello, world make: 'all' is up to date. $ make -j6888

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #4, bug #66499 (group make): Patch sv66499.diff in the attachment sets the write side of the pipe to non blocking mode and keeps writing until EAGAIN. Tested on linux 64 bit. i am going to test on solaris and report later. (file #56663) _

[bug #66490] pattern substitution with % does not match suffixes

Follow-up Comment #1, bug #66490 (group make): In the case of patsubst pattern '.%' does not match input 'bcd.efg'. Same for substitution references. Try something like $(patsubst %.efg,%,$(A)) or B:=$(A:.efg=) ___ Reply to this item at:

Re: '... | Avoiding implicit rule recursion for rule '%/dir: %'. | ...'

On Thu, Nov 7, 2024 at 3:49 AM WaitronCharm via Bug reports and discussion for GNU make wrote: > > all: hello.tsk > > %.tsk: %.o; $(info hello.tsk) > > %.o: %.c %.tsk; $(info hello.c) > Wouldn't this result anyway in a cyclic graph due to '%.tsk'? This is a legal makefile. Make drops the circular

Re: '... | Avoiding implicit rule recursion for rule '%/dir: %'. | ...'

On Tue, Nov 5, 2024 at 8:55 AM WaitronCharm via Bug reports and discussion for GNU make wrote: > Is there any design rationale why 'make' does not like applying the same > pattern rule more than once for the same target? Maybe the authors had some other reason, but the only reason i can see toda

[bug #66381] Stem splitting and directory prefix reconstruction for static pattern rules.

Additional Item Attachment, bug #66381 (group make): File name: sv66381_split_stem.diffSize: 50KiB AGPL NOTICE These attachments are served by Savane. You can download the corresponding source code of Sav

[bug #66381] Stem splitting and directory prefix reconstruction for static pattern rules.

Follow-up Comment #1, bug #66381 (group make): This commit introduces two user visible changes. 1. Split the stem for static pattern rules to dirname and basename. With this feature static pattern rules do the same stem splitting and directory prefix reconstruction as implicit search does for pat

[bug #66381] Stem splitting and directory prefix reconstruction for static pattern rules.

: None Triage Status: None ___ Follow-up Comments: --- Date: Sat 26 Oct 2024 08:38:30 PM UTC By: Dmitry Gon

Re: say which of .PRECIOUS: %.o *.o file.o will actually work

On Thursday, October 10, 2024, Britton Kerin wrote: > On Wed, Oct 9, 2024 at 4:01 PM Dmitry Goncharov wrote: >> >> On Tue, Oct 8, 2024 at 11:16 PM Dan Jacobson wrote: >> > >> > Manual says: >> > >> >You can list the target patte

Re: say which of .PRECIOUS: %.o *.o file.o will actually work

On Tue, Oct 8, 2024 at 11:16 PM Dan Jacobson wrote: > > Manual says: > >You can list the target pattern of an implicit rule (such as '%.o') >as a prerequisite of the special target '.PRECIOUS' to preserve >intermediate files made by implicit rules whose target patterns match >that

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

Follow-up Comment #6, bug #65588 (group make): [comment #5 comment #5:] > I am experiencing a situation with GNU Make 4.4.1 that is I expect will be resolved with the changes under consideration. i expect the same. > Can you possibly advise me how I can test it in my environment. I will build m

[bug #66273] An explicitly mentioned file is not intermediate.

Additional Item Attachment, bug #66273 (group make): File name: sv66273_explicit_file_with_double_colon.diff Size: 3KiB AGPL NOTICE These attachments are served by Savane. You can download th

[bug #66273] An explicitly mentioned file is not intermediate.

Follow-up Comment #1, bug #66273 (group make): Make incorrectly considers an explicitly mentioned file intermediate when the file is a target of a double colon rule. $ ls makefile $ cat makefile hello.x: %.x: %.q; $(info $@ from $<) hello.q::; touch $@ $ # this is make built from master $ rm hel

[bug #66273] An explicitly mentioned file is not intermediate.

: None ___ Follow-up Comments: --- Date: Mon 30 Sep 2024 12:49:34 AM UTC By: Dmitry Goncharov . ___ Reply to this item at:

[bug #66268] Messed up error message about a failure to remove an intermediate file.

Additional Item Attachment, bug #66268 (group make): File name: sv66268_intermfile_removal_error_msg.diff Size: 2KiB AGPL NOTICE These attachments are served by Savane. You can download the corr

[bug #66268] Messed up error message about a failure to remove an intermediate file.

Follow-up Comment #1, bug #66268 (group make): Messed up error message about a failure to remove an intermediate file. $ cat makefile all: hello.x %.x: b/%.q; $(info $@ from $<) b/%.q:; mkdir b; touch $@; chmod -w b $ make mkdir b; touch b/hello.q; chmod -w b hello.x from b/hello.q rm b/hello.qm

[bug #66268] Messed up error message about a failure to remove an intermediate file.

: None Triage Status: None ___ Follow-up Comments: --- Date: Sat 28 Sep 2024 12:38:31 PM UTC By: Dmitry Goncharov . ___ Re

[bug #66073] $? is set incorrectly in the case of grouped targets.

Follow-up Comment #1, bug #66073 (group make): A user reported an issue here https://lists.gnu.org/archive/html/help-make/2024-08/msg1.html. Here is a copy of that email which contains a good description of the issue. Hi. I have two similar Makefiles. [Makefile1] .PHONY: all all: foo.

[bug #66073] $? is set incorrectly in the case of grouped targets.

: None ___ Follow-up Comments: --- Date: Sat 10 Aug 2024 02:15:45 AM UTC By: Dmitry Goncharov . ___ Reply to this i

[bug #66037] An infinite loop with MAKEFLAGS on the command line.

Follow-up Comment #1, bug #66037 (group make): Make enters an infinite loop when some option and MAKEFLAGS= are specified on the command line. Sometimes rather than entering an infinite loop, make exits with an error message, because internal state of getopt is messed up. Here is an example of a

[bug #66037] An infinite loop with MAKEFLAGS on the command line.

Additional Item Attachment, bug #66037 (group make): File name: sv66037_fix.diff Size: 4KiB File name: sv66037_test.diff Size: 2KiB

[bug #66037] An infinite loop with MAKEFLAGS on the command line.

: None ___ Follow-up Comments: --- Date: Sun 28 Jul 2024 11:27:44 PM UTC By: Dmitry Goncharov . ___ Reply to this i

[bug #66011] dependencies after a non-existing file are silently ignored

Follow-up Comment #3, bug #66011 (group make): If you need such a prerequisite and the prerequisite is missing, then the makefile needs to have a rule to build such a prerequisite. Depending on your situation this rule can be either a proper rule or dummy rule like nonexisting.h:; In the end,

[bug #66011] dependencies after a non-existing file are silently ignored

Follow-up Comment #1, bug #66011 (group make): This rule %.o : %.c $(HEADERS) Makefile does not apply because nonexisting.h does not exist. To make there is simply no rule in this makefile to build *.o files. You want to do something like this instead hello.o: $(HEADERS) Makefile %.o : %.c

Re: [PATCH] Fix biased shuffle by avoiding already "struck" elements

On Fri, Jun 21, 2024 at 10:30 AM Paul Smith wrote: > > On Fri, 2024-06-21 at 09:11 -0400, Dmitry Goncharov wrote: > > i hope, Paul approves adding tests of this nature. > > I have no problems with adding unit tests, as long as we can find a way > to integrate it int

Re: [PATCH] Fix biased shuffle by avoiding already "struck" elements

On Wed, Jun 19, 2024 at 5:37 PM Sergei Trofimovich wrote: > Glancing at tests/ all the tests exercise user-facing `make` API. What > would be the best way to validate probabilities? For this type of code like shuffle, i like testing the function itself, directly. Just calling the function in a t

Re: [PATCH] Fix biased shuffle by avoiding already "struck" elements

On Tue, Jun 18, 2024 at 5:38 PM Sergei Trofimovich wrote: > After the change probabilities are not as biased: > > 0 1 2 3 > _ _ _ _ > 0 | 24.99 24.99 25.01 25.01 > 1 | 24.99 25.04 24.99 24.99 > 2 | 25.01 25.00 25.00 24.99 > 3 | 25.01

[bug #65759] handling of "-" and "--" on command line

Follow-up Comment #2, bug #65759 (group make): - is a valid filename. i think, everybody would be better off, with one and only one syntax of having make read from stdin. ___ Reply to this item at:

[bug #60736] Introduce "Circular <- dependency dropped." for .EXTRA_PREREQS deps.

Follow-up Comment #5, bug #60736 (group make): Attached an alternative patch to https://savannah.gnu.org/bugs/index.php?65739. ___ Reply to this item at: __

Re: Treat "Circular dependency...dropped" as a hard error instead?

On Wed, May 8, 2024 at 2:04 PM JZB wrote: > > I have a GNU make-based build system wherein I would like for any/all > GNU make-detected circular dependencies to be treated as a hard error, > i.e., fail [immediately], rather than a "dropped and we go on without > it..." situation. > > Is there a wa

[bug #65739] Add warnings circular-dep and circular-extra-dep.

Follow-up Comment #2, bug #65739 (group make): Here is an example $ cat makefile hello: hello $ make make: circular hello <- hello dependency dropped make: Nothing to be done for 'hello'. $ make --warn=circular-dep:ignore make: Nothing to be done for 'hello'. $ make --warn=circular-dep:error ma

[bug #65739] Add warnings circular-dep and circular-extra-dep.

Additional Item Attachment, bug #65739 (group make): File name: sv65739_circular_dep_warn_part1.diff Size: 6KiB File name: sv65739_circular_dep_warn_part2.diff Size: 6KiB

[bug #65739] Add warnings circular-dep and circular-extra-dep.

Follow-up Comment #1, bug #65739 (group make): Patch sv65739_circular_dep_warn_part1.diff adds warning circular-dep. This warning controls how makes handles circular dependencies. The behavior is to silently drop the dependency, print a message or print a message and exit with an error code. The d

[bug #65739] Add warnings circular-dep and circular-extra-dep.

Status: None ___ Follow-up Comments: --- Date: Tue 14 May 2024 01:40:55 AM UTC By: Dmitry Goncharov . ___ Reply to this i

Re: Treat "Circular dependency...dropped" as a hard error instead?

On Wed, May 8, 2024 at 2:04 PM JZB wrote: >... perhaps a command line option or a ".CIRCULARERROR:" rule > or some way to allow this to be turned on by those who need it? There is currently no mechanism (option or otherwise) to fail on a circular dependency. On top of that, there are situations w

Re: idea: make --show-interpretation

On Mon, May 6, 2024 at 8:26 PM Dan Jacobson wrote: > Have a command that reads in a makefile and outputs the makefile saying > what each part evaluated to. i'd use -p and -n switches. regards, Dmitry

[bug #65685] Submake starts its own jobserver when its recipe contains $(MAKE) $(MFLAGS)

Follow-up Comment #3, bug #65685 (group make): > The way I remember it is that if we see a valid jobserver-auth argument, we ignore the value of -j. My understanding was that we ignore -j that comes from MAKEFLAGS, we still honor -j specified on the command line. > I wonder if we should simply

[bug #65685] Submake starts its own jobserver when its recipe contains $(MAKE) $(MFLAGS)

Follow-up Comment #1, bug #65685 (group make): Make adds '-j' to MAKEFLAGS and MFLAGS when -j is specified on the command line. When MFLAGS that contains -j is expanded in a recipe, the submake gets -j as a command line switch. This causes submake to start its own jobserver and the submake no long

[bug #65685] Submake starts its own jobserver when its recipe contains $(MAKE) $(MFLAGS)

Additional Item Attachment, bug #65685 (group make): File name: sv65685_part1.diff Size: 23KiB File name: sv65685_part2.diff Size: 5KiB

[bug #65685] Submake starts its own jobserver when its recipe contains $(MAKE) $(MFLAGS)

: None Triage Status: None ___ Follow-up Comments: --- Date: Sat 04 May 2024 08:57:53 PM UTC By: Dmitry Goncharov . ___

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

Follow-up Comment #4, bug #65588 (group make): Indeed. Thank you. job.c changed. Paul, do you think we can switch to git branches? i can maintain a branch until merge. i suspect, working with a branch can be easier, than if i attach different versions of a patch. ___

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

Follow-up Comment #2, bug #65588 (group make): sv65588_part1.diff and sv65588_part2.diff fix the buffer overflow. Make (with sv65588_part1.diff and sv65588_part2.diff applied) behaves differently in oneshell mode compared to when .ONESHELL is not specified. Specifically when .ONESHELL is not speci

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

Additional Item Attachment, bug #65588 (group make): File name: sv65588_part3.diff Size: 5KiB AGPL NOTICE These attachments are served by Savane. You can download the corresponding source code of Savane at

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 regardless of how the function

[bug #65596] Test for let function not available in .FEATURES

Follow-up Comment #2, bug #65596 (group make): Other functions are not present in .FEATURES as well. There is really only guile. ___ Reply to this item at:

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

Follow-up Comment #1, bug #65588 (group make): A buffer overflow occurs in oneshell mode when shellflags contains characters special to shell. $ cat makefile .ONESHELL: .SHELLFLAGS:=hello' all:;: $ make Aborted (core dumped) In oneshell mode construct_command_argv_internal wants to store in ar

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

Additional Item Attachment, bug #65588 (group make): File name: sv65588_part1.diff Size: 5KiB File name: sv65588_part2.diff Size: 104KiB

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

: None ___ Follow-up Comments: --- Date: Sat 13 Apr 2024 02:13:34 PM UTC By: Dmitry Goncharov . ___ Reply to this item at:

Re: A question about submitting a new source code file

intending to include that file to a library of mine which is released under the bsd license. Usually, souch source code file would contain something like /* * Copyright (c) 2017 Dmitry Goncharov * * Distributed under the BSD License. * (See accompanying file COPYING). */ Do i understand it

A question about submitting a new source code file

Good morning. Paul, i'd like to contribute another bugfix which involves a brand new source code file. i will assign the ownership to fsf, if needed. However, i'd like to be able to use that source file in my other projects, which are not gpl. i have seen other gnu projects including public domain

Re: A question about hasing in idutils

> It should be easy to fix: swap the bytes in sum_get_unaligned_32. Thanks for the pointer, Andreas. Will try it out. regards, Dmitry

Re: A question about hasing in idutils

Thank you for a quick response, Greg. On Tue, Mar 26, 2024 at 4:56 PM Greg McGary wrote: > The code makes no effort to be endian-independent because it is written > for in-memory hashing on a uniprocessor or homogeneous multiprocessor. Do you know of a specific difficulty of making that hashing

A question about hasing in idutils

Good morning. The hash table from id utils from imported to gnu make. This hash table hashes the same string to different brackets on little and big endian. Can you please shed some light why there needs to be this difference in hashing on little and big endian? regards, Dmitry

[bug #65438] Sort print-targets output.

Follow-up Comment #5, bug #65438 (group make): > Regarding the hashing vs. endianness, I don't know. What do you think of changing hashing to produce the same result on little and big endian? > Regarding sorting, doesn't this basically mean just using strcmp (or a small > wrapper around it) as

[bug #65438] Sort print-targets output.

Follow-up Comment #3, bug #65438 (group make): > I doubt most users will be able to map the output they see onto the input make reads except in simple situations. When you start having lots of include files etc. it becomes hard to follow. i was looking for some useful simple deterministic sorti

[bug #65438] Sort print-targets output.

Additional Item Attachment, bug #65438 (group make): File name: sv65438_fix.diff Size:6 KB File name: sv65438_test.diff Size:3 KB

[bug #65438] Sort print-targets output.

Follow-up Comment #1, bug #65438 (group make): Sort print-targets output. print-targets prints the targets in the order they ended up hashed in the table. The hashing routine hashes differently on big and little endian machines. The result is that the test fails on big endian machines. This is a

[bug #65438] Sort print-targets output.

: None ___ Follow-up Comments: --- Date: Sat 09 Mar 2024 03:34:40 AM UTC By: Dmitry Goncharov . ___ Reply to this item at:

[bug #65360] Extend -p output with export status of each variable.

Follow-up Comment #6, bug#65360 (group make): test3 is not very useful, though, because '/hello/' will match both 'hello' and 'export hello'. ___ Reply to this item at: ___

[bug #65360] Extend -p output with export status of each variable.

Additional Item Attachment, bug#65360 (group make): File name: sv65360_fix3.diff Size:1 KB File name: sv65360_test3.diff Size:3 KB

[bug #65360] Extend -p output with export status of each variable.

Follow-up Comment #5, bug#65360 (group make): An alternative to fix2 can be printing "export" when a variable is exported regardless of the defaults, even for MAKEFLAGS, etc. So, here is patch 3 that does that. ___ Reply to this item at:

[bug #65360] Extend -p output with export status of each variable.

Follow-up Comment #4, bug#65360 (group make): > As for export, would it be better to use the make syntax for this Sure. i attached sv65360_fix2.diff and sv65360_test2.diff. The output is make syntax $ cat makefile hello=world all:; $ ~/src/gmake/make//l64//make -r -p |grep -B1 hello # makefile

[bug #65360] Extend -p output with export status of each variable.

Additional Item Attachment, bug#65360 (group make): File name: sv65360_fix2.diff Size:1 KB File name: sv65360_test2.diff Size:3 KB

[bug #65359] submake might will lose variable values if their names contain special char

Follow-up Comment #3, bug#65359 (group make): Exporting a make variable makes it available for shell in recipes. Removal of a semicolon allows make to avoid shell. Instead makes calls posix_spawn or fork and exec. ___ Reply to this item a

[bug #65360] Extend -p output with export status of each variable.

Additional Item Attachment, bug#65360 (group make): File name: sv65360_fix.diff Size:1 KB File name: sv65360_test.diff Size:4 KB

[bug #65360] Extend -p output with export status of each variable.

Follow-up Comment #1, bug#65360 (group make): This patch has -p print export status, special and conditional flags of each variable. $ ls makefile $ cat makefile hello?=one all:; $ ~/src/gmake/make/l64/make -rp |grep -B1 -w MAKEFLAGS # makefile special export MAKEFLAGS = pr Here make prints

[bug #65360] Extend -p output with export status of each variable.

Triage Status: None ___ Follow-up Comments: --- Date: Sat 24 Feb 2024 02:42:51 PM UTC By: Dmitry Goncharov . ___ Reply to this i

[bug #65324] Fix crash in disable_builtins.

Additional Item Attachment, bug#65324 (group make): File name: sv65324.diff Size:1 KB AGPL NOTICE These attachments are served by Savane. You can download the corresponding source code of Savane at https:/

[bug #65324] Fix crash in disable_builtins.

Follow-up Comment #1, bug#65324 (group make): Make crashes when -r and MAKEFLAGS= are specified on the command line. On startup make begins to process command line arguments. During processing of "MAKEFLAGS=" make calls reset_makeflags, which in turn calls disable_builtins, which dereferences

[bug #65324] Fix crash in disable_builtins.

: None ___ Follow-up Comments: --- Date: Sat 17 Feb 2024 04:27:47 AM UTC By: Dmitry Goncharov . ___ Reply to this item at: <https://savanna

[bug #65323] Functions/shell test 22 causes ksh to crash.

Additional Item Attachment, bug#65323 (group make): File name: sv65323.diff Size:0 KB AGPL NOTICE These attachments are served by Savane. You can download the corresponding source code of Savane at https:/

[bug #65323] Functions/shell test 22 causes ksh to crash.

Follow-up Comment #1, bug#65323 (group make): functions/shell/t022.mk crashes certain shells. E.g. when ksh is used as /bin/sh. That's the test with make exporting a variable whos name is 40K characters long. I tried using perl as a shell, but perl exits with an error message. The patch in the att

[bug #65323] Functions/shell test 22 causes ksh to crash.

: None ___ Follow-up Comments: --- Date: Sat 17 Feb 2024 02:50:44 AM UTC By: Dmitry Goncharov . ___ Reply to this item at:

[bug #63840] make allows match-anything rules to match files with the default suffixes

Follow-up Comment #5, bug#63840 (group make): > Sorry for the delay in examining this bug. Thank you for looking at this. ... > However, I tend to agree with you that this is perhaps too much "inside baseball" for the default behavior. i also think, this is too much to be useful. E.g. in your

Re: Behavior change related to MAKEFLAGS and recursive make in version 4.4.1

On Thu, Jan 25, 2024 at 12:39 PM Ouellette, Paul wrote: > > Hello, > > Consider the following makefiles: > $ cat Makefile > MAKEFLAGS+=VAR=foo > all: > $(info make VAR=$(VAR)) > @echo "env VAR=$$VAR" > $(MAKE) -C lib > $ cat lib/Makefile > all: > @echo "env VAR=$$

[bug #65211] Fix load and loadapi tests.

Additional Item Attachment, bug#65211 (group make): File name: sv65211.diff Size:1 KB AGPL NOTICE These attachments are served by Savane. You can download the corresponding source code of Savane at https:/

[bug #65211] Fix load and loadapi tests.

Follow-up Comment #1, bug#65211 (group make): load and loadapi tests fail when compiler complains about unused variables. E.g. $ cat work/features/load/t004.diff *** t004.base Thu Jan 25 17:30:36 2024 --- t004.logThu Jan 25 17:30:36 2024 *** *** 1,2 --- 1,10 rebuild

  1   2   3   4   5   6   7   8   >