[bug #63307] make 4.4 passes ignored SIGPIPE on to children

Follow-up Comment #11, bug #63307 (project make): [comment #10 comment #10:] > I'm not sure how using a semaphore helps here. We would still have to clean up the semaphore with sem_unlink(). indeed. > The main goal of that change was to allow our cleanup operations to proceed even when SIGPIPE

[bug #63333] Keep running w/o output sync on temp file failure.

Follow-up Comment #1, bug #6 (project make): Make treats inability to create a temporary file for output sync as fatal and aborts the build. $ cat makefile all:; $(info hello, world) $ mkdir temp $ chmod -w temp $ # this is make from master $ TMPDIR=temp ~/src/make/m64/make -Orecurse -j2

[bug #63333] Keep running w/o output sync on temp file failure.

Additional Item Attachment, bug #6 (project make): File name: sv6_test.diff Size:2 KB File name: sv6_fix.diff Size:5 KB

[bug #63333] Keep running w/o output sync on temp file failure.

Follow-up Comment #2, bug #6 (project make): This patch causes make to print an error message and keep running without output sync on a temp file failure. ___ Reply to this item at: __

[bug #63333] Keep running w/o output sync on temp file failure.

Status: None ___ Follow-up Comments: --- Date: Mon 07 Nov 2022 10:49:05 PM UTC By: Dmitry Goncharov . ___ Reply to this i

[bug #63307] make 4.4 passes ignored SIGPIPE on to children

Follow-up Comment #16, bug #63307 (project make): > It appears that make still performs the same build. But maybe I just got something wrong in my test. For example something like this $ cat makefile all: one one: two @echo cp $< $@ >&2 @cp $< $@ two: @echo touch $@

[bug #63307] make 4.4 passes ignored SIGPIPE on to children

Follow-up Comment #17, bug #63307 (project make): > Speaking only for myself, the most realistic scenario I can think of where I would encounter this myself is if I run 'make 2>&1 | less' and then quit less. In that case I would not be interested in having any build continue, I would just want to

[bug #63330] readdir() error in 4.4 on Solaris 8

Follow-up Comment #9, bug #63330 (project make): Depending on _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS dirent has d_ino and d_off fields 32 or 64 bits wide. Looks like in your case the remote machine has 64bit d_ino and d_off and make is built with 32bit d_ino and d_off. i don't see checks for _

[bug #63347] make 4.4 change in behavior for sub-make invoked via $(shell)

Follow-up Comment #1, bug #63347 (project make): This behavior changed to fix https://savannah.gnu.org/bugs/?10593. See commit 98da874c43035a490cdca81331724f233a3d0c9a. ___ Reply to this item at:

[bug #63347] make 4.4 change in behavior for sub-make invoked via $(shell)

Follow-up Comment #5, bug #63347 (project make): Thanks for your report. This patch introduces two visible changes. 1. Have command line variable definitions in MAKEFLAGS at parse time. 2. Define makeflags at parse time, each time a makefile modifies MAKEFLAGS. The patch contains a more detaile

[bug #63417] .NOTINTERMEDIATE with no prerequisites is not working

Follow-up Comment #1, bug #63417 (project make): Thank you for your report. At makefile parse time make processes .NOTINTERMEDIATE and marks all files as notintermediate. The issue with this example, is that at that time make does not yet have a notion of x.b. x.b appears later at build time, whe

[bug #63347] make 4.4 change in behavior for sub-make invoked via $(shell)

Follow-up Comment #9, bug #63347 (project make): > Differences that I could spot: > - there's "rR" instead of "-rR" > - "-rR" is at the beginning not at the end > - MAKE_OPTS are part of MAKEFLAGS -- Well defined MAKEFLAGS has the following format [shortoptions] [-option with arg]... [--long opti

[bug #63347] make 4.4 change in behavior for sub-make invoked via $(shell)

Follow-up Comment #12, bug #63347 (project make): Thanks for review, Paul. Do you think this should be mentioned in NEWS? ___ Reply to this item at: ___

[bug #63439] [Regression] --no-builtin-variables with --warn-undefined-variables trigger warning on GNUMAKEFLAGS

Follow-up Comment #1, bug #63439 (project make): Thank you for your report. This patch runs the lookup for gnumakeflags before decode_env_switches. (file #54041, file #54042) ___ Additional Item Attachment: File name: sv63439_fix.diff

[bug #63439] [Regression] --no-builtin-variables with --warn-undefined-variables trigger warning on GNUMAKEFLAGS

Follow-up Comment #5, bug #63439 (project make): > Exactly how this difference comes to pass is beyond my ken, but there it is... in 4.3 the variable is empty whereas in 4.4 it is undefined. MAKECMDGOALS is undefined in both. make-4.3 is not reporting the undefined variable, because setting 'MAK

[bug #63484] make 4.4 incorrectly thinks target does not exist

Follow-up Comment #1, bug #63484 (project make): Thanks for your report. > test.x exists but make 4.4 says it doesn't This is an old issue, that keeps causing questions. I think, we should open a dedicated bug report about this. > test.foo is older than test.x therefore test.x does not need to

[bug #63510] Confusing "update target 'foo' due to: target does not exist" message

Follow-up Comment #1, bug #63510 (project make): Here is a test case $ ls hello hello $ cat makefile2 .PHONY: hello hello:; touch $@ $ make -f makefile2 --trace makefile2:2: update target 'hello' due to: target does not exist touch hello __

[bug #63537] Regression in switches that can be flipped back and forth.

Status: None ___ Follow-up Comments: --- Date: Fri 16 Dec 2022 07:24:09 PM UTC By: Dmitry Goncharov . ___ Reply to this i

[bug #63537] Regression in switches that can be flipped back and forth.

Additional Item Attachment, bug #63537 (project make): File name: sv63537_doc.diff Size:1 KB ___ Reply to this item at:

[bug #63537] Regression in switches that can be flipped back and forth.

Additional Item Attachment, bug #63537 (project make): File name: sv63537_fix_dash_w_in_makeflags_part1.diff Size:4 KB File name: sv63537_pass_switches_enabled_by_default_part3.diff Size:8 KB

[bug #63537] Regression in switches that can be flipped back and forth.

Follow-up Comment #1, bug #63537 (project make): This bug report is about switches that can be flipped back and forth. Specifically, -S/-k, -w/--no-print-directory and -s/--no-silent. 1. Makefile sets a flag in makeflags and this wipes out the opposite switch specified on the command line. +++

Re: [doc] MAKEOVERRIDES is undocumented

On Mon, Dec 19, 2022 at 11:24 AM Jeffrey Walton wrote: > For the *.pc file, we need '$(prefix)' to survive unexpanded. What about includedir:=$${prefix}/include myconfig.pc:; @echo 'includedir=$(includedir)' >> myconfig.pc ? regards, Dmitry

Re: [doc] MAKEOVERRIDES is undocumented

On Mon, Dec 19, 2022 at 2:33 PM Jeffrey Walton wrote: > Yep, that's why we track both includedir and pc_includedir. You don't have to resort to if statements to initialize either of the variables. regards, Dmitry

Re: [doc] MAKEOVERRIDES is undocumented

On Mon, Dec 19, 2022 at 1:54 PM Alejandro Colomar wrote: > That would render the $(includedir) variable unusable for use within the > Makefile (for example, within targets that install the header files). We can introduce another variable, e.g. myincludedir and initialize it with the expanded valu

Re: [bug #61763] [PATCH] glob: Do not use realloc wrapper on FreeBSD

On Mon, Jan 2, 2023 at 9:50 AM Paul D. Smith wrote: > I decided to own this glob implementation Paul, do you mean that you decided to maintain glob impl in make? If yes, do you still want to link against glibc impl, when available? regards, Dmitry

[bug #14927] Fix for building archive members in parallel

Follow-up Comment #8, bug #14927 (project make): [comment #5 comment #5:] > The disadvantage to this is that the object files are not considered intermediate, and so they are left behind after the build completes rather than being deleted. If this makefile is modified to build a shared object, ra

[bug #63609] Fix a buffer overrun in warn_undefined.

: None ___ Follow-up Comments: --- Date: Tue 03 Jan 2023 05:21:28 AM UTC By: Dmitry Goncharov . ___ Reply to this item at:

[bug #63609] Fix a buffer overrun in warn_undefined.

Follow-up Comment #1, bug #63609 (project make): The following code in warn_undefined causes a buffer overrun if (memcmp (*cp, name, len) == 0 && (*cp)[len] == '\0') when len exceeds strlen (*cp). This happens when make needs to expand a variable whos name is longer than *cp, ___

[bug #63609] Fix a buffer overrun in warn_undefined.

Additional Item Attachment, bug #63609 (project make): File name: sv63609_fix.diff Size:0 KB File name: sv63609_test.diff Size:0 KB

[bug #14927] Fix for building archive members in parallel

Follow-up Comment #14, bug #14927 (project make): Opened a defect report against posix https://austingroupbugs.net/view.php?id=1631 ___ Reply to this item at: _

[bug #63688] Allow env variable AR="ar -X 64"

age Status: None ___ Follow-up Comments: --- Date: Mon 23 Jan 2023 02:50:46 AM UTC By: Dmitry Goncharov . ___ Reply to this it

[bug #63688] Allow env variable AR="ar -X 64"

Follow-up Comment #1, bug #63688 (project make): Bruno reported a test failure on aix with env setting AR="ar -X 64"; https://lists.gnu.org/archive/html/bug-make/2023-01/msg00133.html. This env setting is stored an a perl variable in features/archives and its value is passes to run_make_test like

[bug #63688] Allow env variable AR="ar -X 64"

Additional Item Attachment, bug #63688 (project make): File name: sv63688_quote_arvar_diff Size:0 KB ___ Reply to this item at:

Re: GNU Make 4.4.0.90 on AIX 7.2

On Tue, Jan 17, 2023 at 3:14 AM Bruno Haible wrote: > On AIX 7.2, in 64-bit mode, with the environment variables settings > > CC="xlc -q64 -qthreaded -qtls"; > CXX="xlC -q64 -qthreaded -qtls"; > AR="ar -X 64"; > NM="nm -X 64 -B"; > export CC CXX AR NM > > (with which I build many GNU pac

[bug #63689] Typos

: None ___ Follow-up Comments: --- Date: Mon 23 Jan 2023 03:15:06 AM UTC By: Dmitry Goncharov . ___ Reply to this item at: <https://savannah.gnu.org/bu

[bug #63689] Typos

Follow-up Comment #1, bug #63689 (project make): This patches fixes 2 typos in the manual. (file #54254) ___ Additional Item Attachment: File name: sv63689.diff Size:0 KB

[bug #63690] temp_stdin and output_sync failure on macos

: None ___ Follow-up Comments: --- Date: Mon 23 Jan 2023 03:27:42 AM UTC By: Dmitry Goncharov . ___ Reply to this item at:

[bug #63690] temp_stdin and output_sync failure on macos

Follow-up Comment #1, bug #63690 (project make): Bruno reported that on macos temp_stdin and output_sync tests fail. https://lists.gnu.org/archive/html/bug-make/2023-01/msg00108.html This is the diff. $ cat tests/work/features/temp_stdin.diff.5 *** work/features/temp_stdin.base.5 Sun J

[bug #63690] temp_stdin and output_sync failure on macos

Additional Item Attachment, bug #63690 (project make): File name: sv63690.diff Size:1 KB ___ Reply to this item at:

[bug #63690] temp_stdin and output_sync failure on macos

Follow-up Comment #2, bug #63690 (project make): I tested this patch on linux. However, i could not test this on macos. ___ Reply to this item at: ___ M

[bug #63688] Allow env variable AR="ar -X 64"

Follow-up Comment #2, bug #63688 (project make): Tested on aix, sunos and linux. ___ Reply to this item at: ___ Message sent via Savannah https://savann

Generating missing depfiles by an automake based makefile

Good morning. Here is a rule from an automake generated makefile. $(am__depfiles_remade): @$(MKDIR_P) $(@D) @echo '# dummy' >$@-t && $(am__mv) $@-t $@ This rule restores a missing depfile file by creating a file with one line '# dummy'. (Next version of automake will create an empty one)

Re: Generating missing depfiles by an automake based makefile

On Wed, Feb 8, 2023 at 11:54 AM Jan Engelhardt wrote: > depfiles are created ahead of make so that the include command > in Makefiles succeeds (include-with-ignore is non-portable AFAIR). Atleast, gnu make and sun make can build included files. > depfiles are not specifically tracked; this is i

Re: Generating missing depfiles by an automake based makefile

On Thu, Feb 9, 2023 at 11:41 AM Jan Engelhardt wrote: > This is a GNU extension. Not only gnu. Also supported by sun make. > If you try this with e.g. > OpenBSD make, it will complain. That's why i asked those questions about portability. Do i understand it correctly, that a need to support bma

Re: Generating missing depfiles by an automake based makefile

On Thu, Feb 9, 2023 at 12:15 PM Jan Engelhardt wrote: > On Thursday 2023-02-09 22:53, Dmitry Goncharov wrote: > It would probably take a new m4 macro AM_MAKE_SILENT_INCLUDE that tests > for the availability of "-include", and if found, also somehow changes > the rest of th

Re: Generating missing depfiles by an automake based makefile

On Thursday, February 9, 2023, Tom Tromey wrote: > > > It's been a long time since I worked on automake, but the dependency > tracking in automake is designed not to need to rebuild or pre-build dep > files. Doing that means invoking the compiler twice, which is slow. > Instead, automake computes

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

: None ___ Follow-up Comments: --- Date: Mon 20 Feb 2023 05:52:08 PM UTC By: Dmitry Goncharov . ___ Reply to this item at:

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

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

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

Additional Item Attachment, bug #63821 (project make): File name: sv63821_fix.diff Size:3 KB File name: sv63821_test.diff Size:2 KB

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

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

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

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

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

Follow-up Comment #7, bug #63821 (project make): > We can reconsider it. There is no need. It is all good. I see that you removed parameter void from install_default_suffix_rules definiton. Going forward, do you want empty paranthesis rather than void in functions definition? ___

Re: $(wildcard ...*/) and symlinks

On Fri, Feb 24, 2023 at 6:55 AM Frank Heckenbach wrote: ... > So "*/" ignores the symlink to a file as expected, but "l*/" does > return it, likewise "*/*/" which doesn't make much sense to me. There is a known bug in glibc glob impl. $ ls makefile $ cat makefile all:; $(info $(wildcard hell*/))

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

: None Triage Status: None ___ Follow-up Comments: --- Date: Sun 26 Feb 2023 07:59:52 PM UTC By: Dmitry Goncharov . ___ Re

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

Follow-up Comment #1, bug #63840 (project make): When the built-in rules are disabled, make allows match-anything rules to match files with the default suffixes. Example 1 demonstrates how a match-anything pattern rule incorrectly matches a file with the default suffix when the built-in rules are

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

Additional Item Attachment, bug #63840 (project make): File name: sv63840_fix.diff Size:7 KB File name: sv63840_test.diff Size:9 KB

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

Follow-up Comment #3, bug #63840 (project make): > If you use -r then you've removed all the implicit rules in the makefile, including suffix rules, and so I don't necessarily agree with the idea that even in this case we should still treat these suffixes as special when considering match-anything

[bug #63686] implement a flag to promote make warnings to fatal errors

Follow-up Comment #11, bug #63686 (project make): Paul, if you decide to do the special target, do you intend to let that special target have prerequisites, e.g. targets for which the feature is enabled? ___ Reply to this item at:

Re: 4.4.1 breaks recursive invocation with --print-directory [when adding to MAKEFLAGS]

On Tue, Feb 28, 2023 at 8:41 PM Satish Balay via Bug reports and discussion for GNU make wrote: > $ cat makefile > all: > @MAKEFLAGS="-j1 ${MAKEFLAGS}" ${MAKE} -f makefile hello > hello: > @echo Hello When you pass --print-directory MAKEFLAGS has the value "w". When this makefile

Re: 4.4.1 breaks recursive invocation with --print-directory [when adding to MAKEFLAGS]

On Tue, Feb 28, 2023 at 11:35 PM Satish Balay via Bug reports and discussion for GNU make wrote: > And the reason we use the order '-j8 ${MAKEFLAGS}' is so that we have the > following behavior': > > - invoking 'make' defaults to using a default of '-j8' > - invoking 'make -j4' gives: '-j8 -j4' -

[bug #63867] Port to older versions of gnu tar.

: None ___ Follow-up Comments: --- Date: Sat 04 Mar 2023 02:36:44 PM UTC By: Dmitry Goncharov . ___ Reply to this item at:

[bug #63867] Port to older versions of gnu tar.

Follow-up Comment #1, bug #63867 (project make): GNU tar versions before 1.28 do not accept option --sort. Given --sort, older tar exits with an error message and gzip creates an archive with an empty file. 13 Tests in 9 Categories Failed (See .diff* files in work dir for details) :-( tar:

[bug #63867] Port to older versions of gnu tar.

Additional Item Attachment, bug #63867 (project make): File name: sv63867.diff Size:0 KB ___ Reply to this item at:

[bug #63868] Document MAKEFLASG pitfalls.

: None ___ Follow-up Comments: --- Date: Sat 04 Mar 2023 07:47:49 PM UTC By: Dmitry Goncharov . ___ Reply to this item at:

[bug #63868] Document MAKEFLASG pitfalls.

Follow-up Comment #1, bug #63868 (project make): This patch describes pitfalls of modifications to environment variable MAKEFLAGS. ___ Reply to this item at: __

[bug #63868] Document MAKEFLASG pitfalls.

Additional Item Attachment, bug #63868 (project make): File name: sv63868.diff Size:4 KB ___ Reply to this item at:

Re: No progress output when make 4.4.1 builds Linux 4.19 and earlier

On Wed, Mar 8, 2023 at 1:37 AM Greg KH wrote: > On Tue, Mar 07, 2023 at 10:13:45PM -0800, Eric Biggers wrote: ... > > Is this an intentional breakage from the 'make' side? No it is not an intentional breakage. This is a fix for https://savannah.gnu.org/bugs/?63347. > The fact that kernels 5.4 and

Re: No progress output when make 4.4.1 builds Linux 4.19 and earlier

On Wed, Mar 8, 2023 at 8:58 AM Paul Smith wrote: > Does anyone know why this commit is using a make version comparison? Kernel build system is expected to work with gnu make-3.82. make-3.82 puts long options before short ones. $ cat makefile $(info at parse time makeflags=$(MAKEFLAGS)) all:; $(i

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

[bug #63856] .WAIT does not work as special target on command line.

Additional Item Attachment, bug #63856 (project make): File name: sv63856_part1.diff Size:8 KB File name: sv63856_part2.diff Size:6 KB

[bug #63856] .WAIT does not work as special target on command line.

Follow-up Comment #1, bug #63856 (project make): Thank you for your report. sv63856_part1.diff implements handling of .WAIT on the command line. sv63856_part2.diff fixes pruning of double colon rules. This fix is needed in order for .WAIT to synchronize targets which have multiple double colon ru

[bug #63856] .WAIT does not work as special target on command line.

Additional Item Attachment, bug #63856 (project make): File name: sv63856_fix2_part1.diffSize:11 KB File name: sv63856_fix2_part2.diffSize:15 KB

[bug #63856] .WAIT does not work as special target on command line.

Follow-up Comment #2, bug #63856 (project make): Paul, please disregard sv63856_part1.diff and sv63856_part2.diff. sv63856_fix2_part1.diff and sv63856_fix2_part2.diff contain updated versions of this fix. ___ Reply to this item at:

[bug #63990] Fix a buffer overflow in warning.c.

: None ___ Follow-up Comments: --- Date: Sun 02 Apr 2023 06:38:21 PM UTC By: Dmitry Goncharov . ___ Reply to this item at:

[bug #63990] Fix a buffer overflow in warning.c.

Additional Item Attachment, bug #63990 (project make): File name: sv63990.fixSize:1 KB ___ Reply to this item at:

[bug #63990] Fix a buffer overflow in warning.c.

Follow-up Comment #1, bug #63990 (project make): Settings like .WARNINGS = bogus causes decode_warn_name to return wt_max. decode_warn_actions then stores wt_max in type and the action at data->actions[type] and touches beyond the size of data->actions. __

[bug #63990] Fix a buffer overflow in warning.c.

Follow-up Comment #2, bug #63990 (project make): There is already a test which tests this use case. ___ Reply to this item at: ___ Message sent via Sava

[bug #64016] Simplify update_goal_chain.

: None ___ Follow-up Comments: --- Date: Sat 08 Apr 2023 03:55:58 AM UTC By: Dmitry Goncharov . ___ Reply to this item at:

[bug #64016] Simplify update_goal_chain.

Additional Item Attachment, bug #64016 (project make): File name: sv64016_part1.diff Size:2 KB File name: sv64016_part2.diff Size:0 KB

[bug #64016] Simplify update_goal_chain.

Follow-up Comment #1, bug #64016 (project make): These two small patches modify update_goal_chain to 1. avoid double negation. 2. avoid a redundant ternary operator. Make's behavior is intact. ___ Reply to this item at:

Re: Warnings on '$\\'

On Fri, Apr 14, 2023 at 5:38 AM Gisle Vanem wrote: > But with 'MAKEFLAGS += --warn-undefined-variables', I get a > bunch of warnings: >'reference to undefined variable '\'' > > How can I avoid that? There are various techniques. example 1, define the variable \:= define trace_h #define G_

Re: Warnings on '$\\'

On Mon, Apr 17, 2023 at 3:39 PM Alejandro Colomar wrote: > Dmitry, why did $\\ work for you ($\ being my $(empty)), and not for me > (as $(empty)\)? ¿Cómo estás, Alex? When make parses a definition, first it performs line continuation business, then expands macros. In the case of $(empty)\, mak

[bug #64107] -R and -r settings in MAKEFLAGS are delayed until build time

: None Triage Status: None ___ Follow-up Comments: --- Date: Tue 25 Apr 2023 11:40:58 AM UTC By: Dmitry Goncharov . ___ Reply t

[bug #64107] -R and -r settings in MAKEFLAGS are delayed until build time

Follow-up Comment #1, bug #64107 (project make): $ ls makefile $ cat makefile $(info 0 CC=$(CC), $$(origin CC) = $(origin CC), makeflags = $(MAKEFLAGS)) MAKEFLAGS:=R $(info 1 CC=$(CC), $$(origin CC) = $(origin CC), makeflags = $(MAKEFLAGS)) CC ?= gcc $(info 2 CC=$(CC), $$(origin CC) = $(origin C

[bug #64107] -R and -r settings in MAKEFLAGS are delayed until build time

Additional Item Attachment, bug #64107 (project make): File name: sv64107_fix.diff Size:4 KB File name: sv64107_test.diff Size:2 KB

[bug #64115] make warns about undefined variable GNUMAKEFLAGS

: None ___ Follow-up Comments: --- Date: Wed 26 Apr 2023 11:23:13 AM UTC By: Dmitry Goncharov . ___ Reply to this item at:

[bug #64115] make warns about undefined variable GNUMAKEFLAGS

Follow-up Comment #1, bug #64115 (project make): make warns about undefined variable GNUMAKEFLAGS when -R is specified. $ echo 'all:' | make -f - -R --warn-undefined-variables make: warning: reference to undefined variable 'GNUMAKEFLAGS' make: Nothing to be done for 'all'. $ This patch adds G

[bug #64115] make warns about undefined variable GNUMAKEFLAGS

Additional Item Attachment, bug #64115 (project make): File name: sv64115_fix.diff Size:0 KB File name: sv64115_test.diff Size:1 KB

[bug #64124] Use after free in expand_variable_buf.

: None ___ Follow-up Comments: --- Date: Sat 29 Apr 2023 01:27:06 PM UTC By: Dmitry Goncharov . ___ Reply to this item at:

[bug #64124] Use after free in expand_variable_buf.

Follow-up Comment #1, bug #64124 (project make): There is use after free in expand_variable_buf. When the expanded value of the variable in buf occupies more space than avaiable in variable_buffer, function variable_buffer_output reallocates variable_buffer. This reallocation leaves buf in ex

[bug #64124] Use after free in expand_variable_buf.

Additional Item Attachment, bug #64124 (project make): File name: sv64124_fix.diff Size:1 KB File name: sv64124_test.diff Size:1 KB

[bug #64124] Use after free in expand_variable_buf.

Follow-up Comment #2, bug #64124 (project make): Good news is that this regression was introduced after 4.4.1. ___ Reply to this item at: ___ Message se

[bug #64016] Simplify update_goal_chain.

Follow-up Comment #4, bug #64016 (project make): [comment #2 comment #2:] > I don't understand the test that was added though. How does this test show that both rules are run at the same time? It seems like it would behave the same even if they were not. Indeed. My test was lacking necessary sy

[bug #64016] Simplify update_goal_chain.

Follow-up Comment #5, bug #64016 (project make): This made me think, why don't we also test the opposite situation? That's that in the sequential mode make does not advance to the next target, until the current target is finished. diff --git a/tests/scripts/features/double_colon b/tests/scripts/

[bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

Follow-up Comment #1, bug #64185 (project make): The same behavior can be demonstrated with the following makefile ifdef blah junk: else else endif The parser does not perform variable expansion and ignores rule definitions in conditional branches which are not taken to avoid redundant wor

[bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

Follow-up Comment #2, bug #64185 (project make): It is also necessary to ignore rule definitions in the branches which are not taken from the point of view of correctness. all: hello.tsk hello=1 ifdef hello hello.tsk:; echo true else hello.tsk:; echo false endif Here, we need the 'echo true' r

[bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

Follow-up Comment #6, bug #64185 (project make): > The error is caused not by the else in the recipe, but when adding the $(warning ...) statement immediately preceding the make else. all: ifdef blah junk: else else endif Here, the parser sees rule 'all:' and begins its search for recipe

[bug #64259] Regression in master: make ignores statements it should not ignore.

: None Triage Status: None ___ Follow-up Comments: --- Date: Sat 27 May 2023 03:33:14 PM UTC By: Dmitry Goncharov . ___ Reply t

[bug #64259] Regression in master: make ignores statements it should not ignore.

Additional Item Attachment, bug #64259 (project make): File name: sv64259_fix.diff Size:2 KB File name: sv64259_test.diff Size:1 KB

[bug #64259] Regression in master: make ignores statements it should not ignore.

Follow-up Comment #1, bug #64259 (project make): Commit 07fcee35f058a876447c8a021f9eb1943f902534 introduced a regression. The text in NEWS clarifies that the idea was to never consider a line starting with the recipe prefix as a conditional, to ensure make does not confuse recipe lines with condi

<    1   2   3   4   5   6   7   >