[bug #60799] Parser chokes on second expansion of a prerequisite with ; o #

Follow-up Comment #1, bug #60799 (project make): [comment #0 original submission:] > Parser chokes on second expansion of a prerequisite with ; o # > > $ cat makefile > MAKEFLAGS+=--warn-undefined-variables > .SECONDEXPANSION: > hello: $$(shell echo world;) > touch $@ > > bye:

[bug #60799] Parser chokes on second expansion of a prerequisite with ; o #

URL: Summary: Parser chokes on second expansion of a prerequisite with ; o # Project: make Submitted by: dgoncharov Submitted on: Sat 19 Jun 2021 01:41:58 PM UTC Severity: 3 - Normal

[bug #60777] Command line switch --trace disables -d.

Additional Item Attachment, bug #60777 (project make): File name: sv_60777_fix.diff Size:0 KB File name: sv_60777_test.diff Size:0 KB

[bug #60777] Command line switch --trace disables -d.

URL: Summary: Command line switch --trace disables -d. Project: make Submitted by: dgoncharov Submitted on: Sun 13 Jun 2021 09:16:10 PM UTC Severity: 3 - Normal Item

[bug #60077] Deterministic $@ for grouped targets patch

Follow-up Comment #5, bug #60077 (project make): Todd, thank for your contribution. Your patch is missing second expansion tests. i observe the following misbehavior. $ cat makefile .SECONDEXPANSION: hello world&: $$(info in prereqs @ = $$@, @< = $$(@<), @^ = $$(@^)) $(info in recipe

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

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

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

Follow-up Comment #1, bug #60736 (project make): With the patch in the attachment the output is $ make -f makefile2 make: Circular hello.x <- hello.x dependency dropped. touch hello.x $ ___ Reply to this item at:

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

URL: Summary: Introduce "Circular <- dependency dropped." for .EXTRA_PREREQS deps. Project: make Submitted by: dgoncharov Submitted on: Sun 06 Jun 2021 01:33:46 AM UTC Severity: 3

[bug #60699] Avoid calling strlen repeatedly in a loop.

Follow-up Comment #2, bug #60699 (project make): Sure, here is a unified diff. Rather than attaching diffs, we could submit git branches for review. What do you think? ___ Reply to this item at:

[bug #60699] Avoid calling strlen repeatedly in a loop.

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

[bug #60699] Avoid calling strlen repeatedly in a loop.

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

[bug #60699] Avoid calling strlen repeatedly in a loop.

URL: Summary: Avoid calling strlen repeatedly in a loop. Project: make Submitted by: dgoncharov Submitted on: Sun 30 May 2021 12:08:15 AM UTC Severity: 3 - Normal Item

[bug #60659] Incorrect 2nd expansion of $$< inside a function in the prerequisite list.

Follow-up Comment #3, bug #60659 (project make): Sure, will do. Thanks for review. ___ Reply to this item at: ___ Message sent via Savannah

[bug #60659] Incorrect 2nd expansion of $$< inside a function in the prerequisite list.

Follow-up Comment #1, bug #60659 (project make): Attached tests of explicit and implicit rules and a fix. ___ Reply to this item at: ___ Message sent

[bug #60659] Incorrect 2nd expansion of $$< inside a function in the prerequisite list.

Additional Item Attachment, bug #60659 (project make): File name: sv60659_fix.diff Size:0 KB File name: sv60659_test_implicit.diff Size:3 KB

[bug #60659] Incorrect 2nd expansion of $$< inside a function in the prerequisite list.

URL: Summary: Incorrect 2nd expansion of $$< inside a function in the prerequisite list. Project: make Submitted by: dgoncharov Submitted on: Sun 23 May 2021 02:26:36 PM UTC

[bug #60595] make doesn't always restart when a makefile is rebuilt

Follow-up Comment #1, bug #60595 (project make): Can you please attach a makefile which reproduces the issue? ___ Reply to this item at: ___ Сообщение

Re: Keeping intermediate files

On Thu, May 20, 2021 at 4:29 PM Frank Heckenbach wrote: >- just ".SECONDARY:" with no prerequisites which makes all > targets secondary (like I want), but also makes all targets > immediate, e.g. with this Makefile, if y exists and x doesn't, > it will remake x, but not y,

Re: Manual: Multiple outputs

On Mon, May 3, 2021 at 8:57 AM Paul Smith wrote: > data.h: data.c ; > > (note the extra semicolon). Now it will work. Ofcourse, when data.c is present and data.h is missing, then make will not recreate data.h. It'll run the empty rule. Your original makefile data.h data.c: data.foo

[bug #47880] Allow updates to .INCLUDE_DIRS to change search path

Follow-up Comment #13, bug #47880 (project make): > > My opinion is that the users should not have to know this detail. > I didn't realize you were wearing your 'user' hat! My bad. By "users" here (and in other places) i meant make users, people who write makefiles. In other words, when a user

[bug #47880] Allow updates to .INCLUDE_DIRS to change search path

Follow-up Comment #11, bug #47880 (project make): > Can you use this?: > include $(CURDIR)/foo.mk This indeed suppresses the lookup. My opinion is that the users should not have to know this detail. The behavior should preferably be optimial for the most common scenarios. Also, most (as far as

[bug #60435] Chained pattern rules with multiple targets not removing all intermediate files

Follow-up Comment #1, bug #60435 (project make): i attached 3 patches, the fix, tests and a fix in the doc. Thanks for your report. ___ Reply to this item at:

[bug #60435] Chained pattern rules with multiple targets not removing all intermediate files

Additional Item Attachment, bug #60435 (project make): File name: sv60435_fix.diff Size:3 KB File name: sv60435_doc.diff Size:0 KB

[bug #47880] Allow updates to .INCLUDE_DIRS to change search path

Follow-up Comment #9, bug #47880 (project make): > But, maybe it's better to grab that bull by the horns. >From the user's point of view, it may indeed be better to have a single interface (MAKEFLAGS), which controls the behavior from the makefile. > Regarding removing default directories, I

[bug #47880] Allow updates to .INCLUDE_DIRS to change search path

Follow-up Comment #5, bug #47880 (project make): > The problem is that MAKEFLAGS is only parsed once before all makefiles are read, and again after all makefiles are read. So, this all boils down to having make consider changes to MAKEFLAGS immediately. > I was hoping to avoid adding a new

[bug #47880] Allow updates to .INCLUDE_DIRS to change search path

Follow-up Comment #3, bug #47880 (project make): > The change I have allows someone to reset the search path from within the makefile Awesome. i personally, need this change to be able to skip the default search directories. > In make generally (and, IMO, correctly) the person invoking make

[bug #60412] Avoid default include directories when searching for included files.

Additional Item Attachment, bug #60412 (project make): File name: sv60412_dash_a_test.diff Size:0 KB File name: sv60412_dash_a_doc.diffSize:1 KB

[bug #60412] Avoid default include directories when searching for included files.

Additional Item Attachment, bug #60412 (project make): File name: sv60412_dash_a.diffSize:3 KB ___ Reply to this item at:

[bug #60412] Avoid default include directories when searching for included files.

URL: Summary: Avoid default include directories when searching for included files. Project: make Submitted by: dgoncharov Submitted on: Sat 17 Apr 2021 08:34:55 PM UTC Severity: 3 -

[bug #60378] Avoid duplicates in default_include_directories.

Follow-up Comment #1, bug #60378 (project make): The patch in the attachments compares the value of prefix with one of the hardcoded defaults of default_include_directories and defines INCLUDEDIR only if the specified prefix is different.

[bug #60378] Avoid duplicates in default_include_directories.

Additional Item Attachment, bug #60378 (project make): File name: sv60378_no_dups_in_default_include_directories.diff Size:1 KB ___

[bug #60378] Avoid duplicates in default_include_directories.

URL: Summary: Avoid duplicates in default_include_directories. Project: make Submitted by: dgoncharov Submitted on: Mon 12 Apr 2021 01:19:21 AM UTC Severity: 3 - Normal

Re: .SECONDARY: unwanted effect of not causing rebuilds when intermediate files missing

On Mon, Apr 5, 2021 at 7:28 PM Britton Kerin wrote: > Even if this behavior of .SECONDARY: is considered desirable Whether or not it is desirable, it is there and there are makefiles which use it and a change would break them. >, it would > be nice to have some way of telling make what I want

[bug #60297] optimize autodeps

Follow-up Comment #17, bug #60297 (project make): > Just a note, in various examples you give prerequisites to the .SECONDEXPANSION target; these are ignored. Indeed, i was thinking about having this feature and added %.o, but should not have. > there's already a lot of complexity around

[bug #60297] optimize autodeps

Follow-up Comment #14, bug #60297 (project make): Let me provide a verbose description of .NOTINTERMEDIATE here. This piece of make code allows to get rid from include directive with generated dep files. Motivation for this piece of make code is described as 1,2,3 and 4 in update 6.

[bug #60297] optimize autodeps

Follow-up Comment #12, bug #60297 (project make): > Yes, I'm saying we already have a way to mark things "not intermediate" (.SECONDARY) The only difference between that and a brand new .NOTINTERMEDIATE you have proposed is that .SECONDARY doesn't handle patterns and .NOTINTERMEDIATE does.

Re: Intermediate file removal ... considered harmful??

On Wed, Mar 31, 2021 at 5:39 PM Paul Smith wrote: > Third, there's not a flexible way to disable intermediate files: agree. > I think it is still useful to keep intermediate files as a concept, > where if an intermediate file in a chain of implicit rules doesn't > exist but the mod time of the

[bug #60312] echo replaces double quote with backslash

Follow-up Comment #1, bug #60312 (project make): Make passes recipies to shell line by line. Shell runs echo. You can see here echo 'nospacebefore:"xx"' nospacebefore:\xx" The first line is what make passes to shell. The 2nd line is the result of echo. Apparently, echo on your system does this.

[bug #60297] optimize autodeps

Follow-up Comment #8, bug #60297 (project make): i read that article several times and indeed found it interesting. In fact, i was using the technique described in your article, until my use cases forced me to come up with the technique described here.

[bug #60297] optimize autodeps

Follow-up Comment #5, bug #60297 (project make): i noticed that something messed up tabs in the examples in the original submission. Please disregard original submission. Let me resubmit. ___ Reply to this item at:

[bug #60297] optimize autodeps

Follow-up Comment #6, bug #60297 (project make): The modern technique of tracking dependencies uses include directive. While this technique is infinitely superior to the manual maintenance of deps there is still room for improvement. 1. include is not a part of the dag. src:=$(wildcard *.c)

[bug #60297] optimize autodeps

Follow-up Comment #4, bug #60297 (project make): Typo. sv60297_notintermediate.diff contains implementation of special target *.NOTINTERMEDIATE.* ___ Reply to this item at:

[bug #60297] optimize autodeps

Follow-up Comment #3, bug #60297 (project make): sv60297_notintermediate_doc.diff is a doc. ___ Reply to this item at: ___ Message sent via Savannah

[bug #60297] optimize autodeps

Follow-up Comment #2, bug #60297 (project make): sv60297_notintermediate_test.diff is a test. ___ Reply to this item at: ___ Message sent via Savannah

[bug #60297] optimize autodeps

Follow-up Comment #1, bug #60297 (project make): sv60297_notintermediate.diff is implementation of special target .INTERMEDIATE. (file #51149, file #51150, file #51151) ___ Additional Item Attachment: File name:

[bug #60297] optimize autodeps

URL: Summary: optimize autodeps Project: make Submitted by: dgoncharov Submitted on: Sun 28 Mar 2021 01:06:47 AM UTC Severity: 3 - Normal Item Group: Enhancement

[bug #60281] Directory in directory in $PATH shadows binaries in $PATH

Follow-up Comment #1, bug #60281 (project make): This is a duplicate of https://savannah.gnu.org/bugs/index.php?57962. ___ Reply to this item at: ___

[bug #60188] Explicit file built by an implicit rule is not intermediate.

Follow-up Comment #5, bug #60188 (project make): Paul, i attached one more test sv60188_explicit_intermediate_test.diff. This one tests that an explicitly mentioned file is still intermediate when it is a prereq to .INTERMEDIATE. ___

[bug #60188] Explicit file built by an implicit rule is not intermediate.

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

[bug #60188] Explicit file built by an implicit rule is not intermediate.

Follow-up Comment #4, bug #60188 (project make): Thank you, Paul. 1. Do you mean something like CC="@echo cc" ? 2. sure 3. By the old style do you mean run_make_with_options? ___ Reply to this item at:

[bug #60188] Explicit file built by an implicit rule is not intermediate.

Follow-up Comment #1, bug #60188 (project make): sv60188_explicit_file_built_by_implicit_rule_is_not_intermediate.diff contains a fix. All other attached patches contain new tests. Even though the fix is not related to static pattern rules, i added a test for static pattern rules to cover all

[bug #60188] Explicit file built by an implicit rule is not intermediate.

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

[bug #60188] Explicit file built by an implicit rule is not intermediate.

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

[bug #60188] Explicit file built by an implicit rule is not intermediate.

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

[bug #60188] Explicit file built by an implicit rule is not intermediate.

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

[bug #60188] Explicit file built by an implicit rule is not intermediate.

Additional Item Attachment, bug #60188 (project make): File name: sv60188_patternrules_test.diff Size:2 KB ___ Reply to this item at:

[bug #60188] Explicit file built by an implicit rule is not intermediate.

Additional Item Attachment, bug #60188 (project make): File name: sv60188_explicit_file_built_by_implicit_rule_is_not_intermediate.diff Size:5 KB

[bug #60188] Explicit file built by an implicit rule is not intermediate.

URL: Summary: Explicit file built by an implicit rule is not intermediate. Project: make Submitted by: dgoncharov Submitted on: Sun 07 Mar 2021 07:02:23 PM UTC Severity: 3 - Normal

Re: gmake and ccache conspiring together in creating gremlins

On Tue, Feb 9, 2021 at 5:31 AM Edward Welbourne wrote: > Rather than removing the jobserver-auth data, you could amend the > MAKEFLAGS to includ jobserver-auth data with plainly invalid fds, i like jobserver-auth data with plainly invalid fds, because it lets older binaries fail on parsing

Re: gmake and ccache conspiring together in creating gremlins

On Mon, Feb 8, 2021 at 12:36 PM Edward Welbourne wrote: > Sounds to me like that's a bug: when the descriptors are closed, the > part of MAKEFLAGS that claims they're make's jobserver file descriptors > should be removed, since that's when the claim stops being true. make uses posix_spawn by

Re: gmake and ccache conspiring together in creating gremlins

On Mon, Feb 8, 2021 at 12:51 PM Dmitry Goncharov wrote: > > On Mon, Feb 8, 2021 at 12:36 PM Edward Welbourne > wrote: > > Sounds to me like that's a bug: when the descriptors are closed, the > > part of MAKEFLAGS that claims they're make's jobserver file descriptors > &g

[bug #59956] Recipes inside conditionals can break the parser

Follow-up Comment #8, bug #59956 (project make): i mean, the user would tell make through some option (a special target or even presence of ".else" in the makefile) "this makefile uses .else, rather then else". make then would not consider "else" a keyword. The keyword does not have to be

[bug #59956] Recipes inside conditionals can break the parser

Follow-up Comment #6, bug #59956 (project make): What about adding another keyword, e.g. .else? ___ Reply to this item at: ___ Message sent via

[bug #59881] Segmentation Fault through manipulated Makefile

Follow-up Comment #3, bug #59881 (project make): Thank you for your report. How did you manage to obtain this makefile? ___ Reply to this item at: ___

[bug #59881] Segmentation Fault through manipulated Makefile

Follow-up Comment #2, bug #59881 (project make): Here is a test. diff --git a/tests/scripts/functions/error b/tests/scripts/functions/error index 998afe4..cb8fcc4 100644 --- a/tests/scripts/functions/error +++ b/tests/scripts/functions/error @@ -63,6 +63,28 @@ $answer = "Some

[bug #59881] Segmentation Fault through manipulated Makefile

Follow-up Comment #1, bug #59881 (project make): This makefile causes variable_buffer_output to realloc. This renders buffer in enter_prereqs invalid. Here is a patch. diff --git a/src/file.c b/src/file.c index a979ca5..61f0a56 100644 --- a/src/file.c +++ b/src/file.c @@ -524,8 +524,12 @@

[bug #59870] Segmentation Fault on GNU

Follow-up Comment #1, bug #59870 (project make): Here is a patch. i am not adding a test, because there is a commented out test 19 in targetvars, which expects different behavior. Thank you for your report and the test case. diff --git a/src/read.c b/src/read.c index 545514c..11ef748 100644 ---

Re: AW: Issue with VPN

> Question. Is there a change to optimize the function cp and rm? In bash (in recipe lines) you can replace cp with echo "$(dst in make you can replace cp with $(file >dst,$(file

[bug #59762] make --touch produce local spurious empty files with out-of-tree Makefile strategy

Follow-up Comment #1, bug #59762 (project make): You target.mk contains rule % :: $(DIR_TARGET) ; : When you run $ make file1.o make finds this rule, with % being file1.o and its prerequisite being build. Make then makes this prerequisite and then proceeds to execute the recipe to make file1.o

[bug #59601] buffer over-read on malformed environment variable

Follow-up Comment #2, bug #59601 (project make): Thanks for your report. Here is a patch. diff --git a/src/main.c b/src/main.c index 9066513..64e2529 100644 --- a/src/main.c +++ b/src/main.c @@ -1364,7 +1364,7 @@ main (int argc, char **argv, char **envp) enum variable_export export =

Re: [bug #59399] Expanding implicit macros in gmake (enhancement request)

On Sun, Nov 29, 2020 at 6:02 PM Jörg Schilling wrote: > I just verified that expanding $< and $* for explicit rules at all > was an invention from SunPro Make. These macros have not been > expanded by the classical UNIX make. The seminal make manual of 1978 contains the following "Before

[bug #59490] target may not be remade if prerequisite has no recipe

Follow-up Comment #2, bug #59490 (project make): Greg, you observe the effect of make fs cache. In order to avoid this effect you need to tell make explicitly that c1 is to be rebuilt when b1 changes. e.g. b1: a1 touch b1 c1: b1 touch c1 d1: c1 touch d1

Re: embedded newlines in shell function variable expansion

On Fri, Oct 9, 2020 at 11:11 AM Byrnes, Robert wrote: > > If I use this Makefile ... > > > bash$ cat Makefile > FOO := $(shell echo $(ENTRIES) ; ) > BAR := $(shell echo $(ENTRIES) ) > > all: > @echo FOO = $(FOO) > @echo BAR = $(BAR) > > .PHONY: all >

[bug #59247] function shell eats a newline

Follow-up Comment #1, bug #59247 (project make): The patch in the attachment fixes the issue. ___ Reply to this item at: ___ Message sent via Savannah

[bug #59247] function shell eats a newline

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

[bug #59247] function shell eats a newline

URL: Summary: function shell eats a newline Project: make Submitted by: dgoncharov Submitted on: Sat 10 Oct 2020 06:24:33 PM UTC Severity: 3 - Normal Item Group: None

[bug #59230] Conditional assigment of a target specific variable prevents export

URL: Summary: Conditional assigment of a target specific variable prevents export Project: make Submitted by: dgoncharov Submitted on: Tue 06 Oct 2020 10:38:50 PM UTC Severity: 3 -

[bug #59230] Conditional assigment of a target specific variable prevents export

Follow-up Comment #3, bug #59230 (project make): That is assignment of a global variable prevents export of a target specific variable. ___ Reply to this item at:

[bug #59230] Conditional assigment of a target specific variable prevents export

Additional Item Attachment, bug #59230 (project make): File name: sv59230_assignment_of_a_global_variable_prevents_export_of_a_target_specific_variable.diff Size:1 KB

[bug #59230] Conditional assigment of a target specific variable prevents export

Follow-up Comment #4, bug #59230 (project make): The second patch fixes this second issue. ___ Reply to this item at: ___ Message sent via Savannah

[bug #59230] Conditional assigment of a target specific variable prevents export

Follow-up Comment #1, bug #59230 (project make): The attached patch fixes the issue. ___ Reply to this item at: ___ Message sent via Savannah

[bug #59230] Conditional assigment of a target specific variable prevents export

Follow-up Comment #2, bug #59230 (project make): However, the following example still fails, even with the attached patch applied. $ cat makefile all:; @echo hello=$$hello hello=sun dummy: hello?=world $ hello=moon make hello= ___

[bug #59230] Conditional assigment of a target specific variable prevents export

Additional Item Attachment, bug #59230 (project make): File name: sv59230_conditional_assignment_of_a_target_var Size:1 KB ___ Reply to

Re: GNU Make 4.3: Makefile rule spooky action at a distance

On Sun, Oct 4, 2020 at 9:32 AM Danny Milosavljevic wrote: > I just got a build failure in lz4. I've isolated it and made a minimal test > case, see below. ... I opened https://savannah.gnu.org/bugs/index.php?59230 and attached 2 patches which fix this issue that you observed and a similar

[bug #59093] Segmentation fault regression in make 4.3 vs. 4.2.1

Follow-up Comment #5, bug #59093 (project make): The only issue i encountered with make children inheriting a high value of RLIMIT_STACK was a 32 bit compiler running out of heap when compiling a large file. i attached another patch. This patch sets stack limit to a default hardcoded value when

[bug #59093] Segmentation fault regression in make 4.3 vs. 4.2.1

Additional Item Attachment, bug #59093 (project make): File name: defss.diff Size:2 KB ___ Reply to this item at:

[bug #59093] Segmentation fault regression in make 4.3 vs. 4.2.1

Follow-up Comment #2, bug #59093 (project make): This patch in the attachment solves the issue. ___ Reply to this item at: ___ Message sent via

[bug #59093] Segmentation fault regression in make 4.3 vs. 4.2.1

Additional Item Attachment, bug #59093 (project make): File name: sv59093_set_stack_size.diffSize:0 KB ___ Reply to this item at:

[bug #59093] Segmentation fault regression in make 4.3 vs. 4.2.1

Follow-up Comment #1, bug #59093 (project make): This is caused by stack overflow. A change introduced in commit 4f3a41c60a02f6df9fc0725698ade64825907822 prevents setting stack size if posix_spawn is used. ___ Reply to this item at:

[bug #59096] The built in rule for archives fails on aix.

Follow-up Comment #1, bug #59096 (project make): This is a patch which fixes this rule. diff --git a/src/default.c b/src/default.c index 751ea15..7d31355 100644 --- a/src/default.c +++ b/src/default.c @@ -71,6 +71,9 @@ static struct pspec default_pattern_rules[] = #else { "(%)", "%",

[bug #59096] The built in rule for archives fails on aix.

URL: Summary: The built in rule for archives fails on aix. Project: make Submitted by: dgoncharov Submitted on: Чт 10 сен 2020 23:40:31 Severity: 3 - Normal Item Group:

[bug #58979] Recursive make using jobserver hangs at completion

Follow-up Comment #11, bug #58979 (project make): > but I have never put '+' on any recipes. When is that needed? '+' cause make to keep the jobserver pipe fd open on exec of that command and also run the command regardless of -n, -p, -q.

[bug #58979] Recursive make using jobserver hangs at completion

Follow-up Comment #10, bug #58979 (project make): > No. It did not hang. -n causes make to run only recursive commands. And the hang does not reproduce with -n. Which makes us suspect all the other (not recursive) commands. There are atleast the following debugging options. Remove recipies one

[bug #58979] Recursive make using jobserver hangs at completion

Follow-up Comment #8, bug #58979 (project make): > I've attached my makefiles. i guess, a clarification is needed. The attached makefiles are a part of a bigger system. The other part is missing. It is not possible to reproduce the issue with the attached makefiles for anyone who is missing the

[bug #58979] Recursive make using jobserver hangs at completion

Follow-up Comment #3, bug #58979 (project make): David, can you please attach the makefiles which reproduce the issue? ___ Reply to this item at: ___

[bug #58961] Document dynamic phony targets.

Follow-up Comment #1, bug #58961 (project make): Please use the latest attached file. ___ Reply to this item at: ___ Message sent via Savannah

[bug #58961] Document dynamic phony targets.

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

[bug #58961] Document dynamic phony targets.

URL: Summary: Document dynamic phony targets. Project: make Submitted by: dgoncharov Submitted on: Sat 15 Aug 2020 02:44:41 PM UTC Severity: 3 - Normal Item Group:

[bug #58960] Fix a typo in the manual

URL: Summary: Fix a typo in the manual Project: make Submitted by: dgoncharov Submitted on: Sat 15 Aug 2020 02:42:53 PM UTC Severity: 3 - Normal Item Group: None

[bug #58734] gmake does not check for the existence of a file before complaining it is missing

Follow-up Comment #1, bug #58734 (project make): Can you please attach a makefile that demonstrates the issue? ___ Reply to this item at: ___

<    1   2   3   4   5   6   7   >