[dgoncha...@users.sf.net: [PATCH] uninitialized variable in parse_file_seq]

glob/glob.c touches this variable when the user passes a pattern with a trailing slash to wildcard. regards, Dmitry diff --git a/src/read.c b/src/read.c index db1a42d..2e44d5e 100644 --- a/src/read.c +++ b/src/read.c @@ -3065,6 +3065,7 @@ parse_file_seq (char **stringp, unsigned int size, int

[PATCH] add wildcard tests

These are wildcard tests that pass patterns with trailing slash. These tests verify the glob patch sent in a separate email. regards, Dmitry diff --git a/tests/run_make_tests.pl b/tests/run_make_tests.pl index cd8a643..99d56bc 100644 --- a/tests/run_make_tests.pl +++ b/tests/run_make_tests.pl @@

[dgoncha...@users.sf.net: [PATCH] use own copy of glob.c]

glibc's glob.c currently does not handle patterns with a trailing slash correctly. https://sourceware.org/bugzilla/show_bug.cgi?id=22513. This patch switches to gmake's own implementaion of glob until glibc is fixed. Once glibc is fixed a version check can be added. If the tests patch submitted

[PATCH] fix wildcard when pattern has a trailing slash.

If patterns has a trailing slash then glob has to match directories only. If the pattern is only 2 characters long (e.g. */) glob already matches directories only. If the pattern is longer e.g. hello*/ then glob matches only directories or files and directoires depending on type in

Re: Handling posix_spawn for non-existent binaries

On Wed, Jul 17, 2019 at 12:38 PM Paul Smith wrote: ... > The only idea I have so far is to try to detect when this situation > occurs (by looking for the 127 exit status) then using stat() to check > to see if the binary exists (I suppose I need to check for executable > status) and generating

[bug #57022] Error 127 executing a script with no #!

Follow-up Comment #6, bug #57022 (project make): Submitted a new test features/exec which reproduces this bug. https://lists.gnu.org/archive/html/bug-make/2019-10/msg00046.html ___ Reply to this item at:

[bug #57242] Non-recursive command passes invalid jobserver file descriptors

Follow-up Comment #1, bug #57242 (project make): Stefan, the behavior you described is intended. make closes the pipe unless the command has + or (MAKE) or {MAKE}. This is necessary, because a command can mess up job server operation or a command may expect a specific fd to be available.

[bug #57022] Error 127 executing a script with no #!

Follow-up Comment #4, bug #57022 (project make): 1. gmake posix_spawn's dodgy 2. fork inside posix_spawn succeeds and posix_spawn returns 0. 3. gmake skips fallback to /bin/sh because posix_spawn's return code is not enoexec. 4. posix_spawn's child proceeds to exec dodgy and fails 5. posix_spawn

[bug #57778] Stop looking for an included file once found, even if cannot be opened.

URL: Summary: Stop looking for an included file once found, even if cannot be opened. Project: make Submitted by: dgoncharov Submitted on: Sun 09 Feb 2020 05:07:07 PM UTC Severity: 3

[bug #57962] apparent regression involving PATH resolution

Follow-up Comment #4, bug #57962 (project make): The bug is in gnulib in function find_in_given_path. This is a patch which fixes the bug. The fix is likely needed for the windows specific piece of code in find_in_given_path as well. regards, Dmitry diff --git a/lib/findprog-in.c

[bug #57962] apparent regression involving PATH resolution

Follow-up Comment #3, bug #57962 (project make): This is a test which reproduces the bug. The bug only manifests when USE_POSIX_SPAWN is defined. regards, Dmitry diff --git a/tests/scripts/features/exec b/tests/scripts/features/exec

[bug #57962] apparent regression involving PATH resolution

Follow-up Comment #5, bug #57962 (project make): i also submitted this patch to bug-gnulib mailing list. ___ Reply to this item at: ___ Message sent

[bug #57676] openjdk11 fails to build with make 4.3

Follow-up Comment #10, bug #57676 (project make): Here is a test for this. +# Test 20. +# When successfully read an included makefile, update its mtime, if needed. +# https://savannah.gnu.org/bugs/?57676. + +unlink('hello.mk'); +run_make_test(q! +-include hello.mk +$(shell echo hello=world

[bug #57676] openjdk11 fails to build with make 4.3

Follow-up Comment #9, bug #57676 (project make): make should not claim "cannot make the included makefile" having successfully read the makefile. Here is a patch which fixes the issue. regards, Dmitry diff --git a/src/makeint.h b/src/makeint.h index c428a36..327849b 100644 --- a/src/makeint.h

[bug #56301] Mandatory/Optional include files and pattern rule with multi-targets

Follow-up Comment #3, bug #56301 (project make): These patches are against the current master (0c326a66c9eb3a3b5e4ab7892578b016b0590b1f). ___ Reply to this item at:

[bug #55242] Included Makefile not found, no rule to build it but make does not fail

Follow-up Comment #1, bug #55242 (project make): Here is a patch against the current master (0c326a66c9eb3a3b5e4ab7892578b016b0590b1f). This patch causes make to re-execute itself to read the included makefile. diff --git a/src/remake.c b/src/remake.c index fb237c5..4dc91d8 100644 ---

[bug #55242] Included Makefile not found, no rule to build it but make does not fail

Follow-up Comment #2, bug #55242 (project make): Here is a test. diff --git a/tests/scripts/features/include b/tests/scripts/features/include index 0c63c06..f39e5ec 100644 --- a/tests/scripts/features/include +++ b/tests/scripts/features/include @@ -260,4 +260,16 @@ inc1:; @%s $@ && echo FOO :=

[bug #56301] Mandatory/Optional include files and pattern rule with multi-targets

Follow-up Comment #4, bug #56301 (project make): This test is the same as the one submitted earlier, but unlinks the included makefiles. diff --git a/tests/scripts/features/include b/tests/scripts/features/include index 0c63c06..4401622 100644 --- a/tests/scripts/features/include +++

[bug #55242] Included Makefile not found, no rule to build it but make does not fail

Additional Item Attachment, bug #55242 (project make): File name: sv_55242_let_included_files_be_byproduct_of_unrelated_rules.diff Size:2 KB File name:

[bug #56301] Mandatory/Optional include files and pattern rule with multi-targets

Follow-up Comment #2, bug #56301 (project make): Here is a test. diff --git a/tests/scripts/features/include b/tests/scripts/features/include index 0c63c06..2281ee4 100644 --- a/tests/scripts/features/include +++ b/tests/scripts/features/include @@ -260,4 +260,13 @@ inc1:; @%s $@ && echo FOO :=

[bug #56301] Mandatory/Optional include files and pattern rule with multi-targets

Follow-up Comment #1, bug #56301 (project make): Here is a fix. diff --git a/src/main.c b/src/main.c index bcba2d1..5c1a7da 100644 --- a/src/main.c +++ b/src/main.c @@ -2305,6 +2305,8 @@ main (int argc, char **argv, char **envp) any_remade |= (mtime != NONEXISTENT_MTIME

[bug #58056] Forced prerequisite order is not honored with pattern rules

Follow-up Comment #1, bug #58056 (project make): This behavior is intended. 1. To figure out if a target has to be rebuilt make traverses the list of prerequisites and finds out if any of the prerequisites, but not intermediate prerequisites, need to be rebuilt. During this traverse make

[bug #58365] make 4.3 segfault on s390x alpine linux

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

[bug #58013] .SILENT appears to be ignored in GNU Make 4.3

Follow-up Comment #1, bug #58013 (project make): This is intentional. See https://savannah.gnu.org/bugs/?54740. ___ Reply to this item at: ___ Message

[bug #58013] .SILENT no longer suppresses "Entering directory"

Follow-up Comment #7, bug #58013 (project make): Posix is explicit that -s and .SILENT are both about command lines. If we wanted to be strictly posix conformant 'Entering directory' should be printed even when -s is specified. if .SILENT is stretched to suppress other messages such as 'Entering

[bug #58013] .SILENT no longer suppresses "Entering directory"

Follow-up Comment #4, bug #58013 (project make): "Entering directory' message when the user is not expecting one is a benign backward incompatibility. i'd be more concern about the opposite. Also, reinstating the prior behavior is incompatible with 4.3.

[bug #58435] make 4.3 is not c89 compliant

Follow-up Comment #2, bug #58435 (project make): This code was introduced when a local implementation of strerror was replaced with gnulib's one. commit 4d00ceba264a9fd04241dcd2685526ce64c1346b Author: Paul Smith Date: Sat Jul 13 08:34:45 2019 -0400 Switch to the gnulib version of

[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 #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 #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 #2, bug #59093 (project make): This patch in the attachment solves the issue. ___ Reply to this item at: ___ Message sent via

[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

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

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 #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

[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 #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 #3, bug #58979 (project make): David, can you please attach the makefiles which reproduce the issue? ___ Reply to this item at: ___

[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 #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 #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 #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 #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 #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: ___

[bug #58639] Shortest stem not matched

Follow-up Comment #2, bug #58639 (project make): Paul, do you think we can describe this scenario this explicitly in the doc? E.g. diff --git a/doc/make.texi b/doc/make.texi index 733c0b9..9c625d7 100644 --- a/doc/make.texi +++ b/doc/make.texi @@ -10342,9 +10342,9 @@ A pattern rule can be used

[bug #58529] MAKEOVERRIDES does not change the origin

Follow-up Comment #2, bug #58529 (project make): make manual specifies that the only thing legal to do with MAKEOVERRIDES is to reset it. Why do you want to set new contents of MAKEOVERRIDES? MAKEOVERRIDES is not intended for this use. You can override a variable using override. override FOO=z

[bug #58497] inconsistent newline removal in $(file <)

Follow-up Comment #1, bug #58497 (project make): Attached another fix along with new tests. ___ Reply to this item at: ___ Message sent via Savannah

[bug #58497] inconsistent newline removal in $(file <)

Additional Item Attachment, bug #58497 (project make): File name: sv_58497_fix_function_file.diff Size:0 KB File name: sv_58497_fix_function_file_tests.diff Size:2 KB

[bug #58497] inconsistent newline removal in $(file <)

Follow-up Comment #2, bug #58497 (project make): However, i'd like to be able to reproduce realloc returning a smaller address. Ken, do you have a makefile which reproduces this? ___ Reply to this item at:

[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 =

[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 #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

[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 #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 #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 ---

[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 #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 #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 #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 #

Follow-up Comment #3, bug #60799 (project make): Yes, it is possible to store special characters in a variable. i'd not bother fixing this, if not for the fact that make already supports this input. It is just when second expansion is enabled the parser fails. i don't think this inconsistency

[bug #60811] Add long-form aliases for automatic variables

Follow-up Comment #1, bug #60811 (project make): $<, $@, etc are the portable automatic variables. These are standardized by posix and supported by other unix makes, e.g. sun and ibm makes. On the other hand, .IMPSRC, etc are not portable. Introduction of .IMPSRC to gmake cannot improve

[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 #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: ___ Сообщение

[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.

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.

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 #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.

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 #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 #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 #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 #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.

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.

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 #60904] More accurate description of intermediate files

URL: Summary: More accurate description of intermediate files Project: make Submitted by: dgoncharov Submitted on: Sat 10 Jul 2021 02:53:15 PM UTC Severity: 3 - Normal

[bug #60904] More accurate description of intermediate files

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

[bug #60841] misleading statement in the manual

URL: Summary: misleading statement in the manual Project: make Submitted by: dgoncharov Submitted on: Sun 27 Jun 2021 09:57:28 PM UTC Severity: 3 - Normal Item Group:

[bug #60841] misleading statement in the manual

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

[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 #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 #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 #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 #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 #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 #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 #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.

[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 #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 #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:

  1   2   3   4   5   6   7   >