[bug #57914] abspath does resolve symlink

Follow-up Comment #8, bug #57914 (project make): Right... GNU make doesn't have any option to act like "pwd -L" does when it manages paths. The user could do that themselves in their makefile since they have access to "$(PWD)". Maybe not pretty, but something like this could work: labspath = $

[bug #57674] GNU make doesn't use default path if PATH not set

Update of bug #57674 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM _

[bug #57674] GNU make doesn't use default path if PATH not set

Update of bug #57674 (project make): Summary: regression in make 4.3 with makefile from stdin => GNU make doesn't use default path if PATH not set ___ Reply to this item at: _

[bug #57674] regression in make 4.3 with makefile from stdin

Follow-up Comment #2, bug #57674 (project make): I know why this happens. In GNU make prior to 4.3 we used the execvp() system call to invoke commands. This call behaves like this (from the man page): > The file is sought in the colon-separated list of directory pathnames > specified in the PAT

[bug #57914] abspath does resolve symlink

Update of bug #57914 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #6: Just as another proof

[bug #57896] Incorrect directory is printed in "Entering directory" message when -j1 disables jobserver mode for a sub make

Update of bug #57896 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM _

[bug #57967] make messes up the terminal

Update of bug #57967 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Component Version:

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

Follow-up Comment #9, bug #58013 (project make): FWIW I thought of another way to do this in a portable way: submake: ; GNUMAKEFLAGS=--no-print-directory $(MAKE) recurse or some form of that. ___ Reply to this item at:

[bug #57962] apparent regression involving PATH resolution

Follow-up Comment #1, bug #57962 (project make): If you change your rule to add a special character, does it start to work? For example if you switch it to something like: all: which perl :; perl -le 'print "HELLO"' ___

[bug #57866] make fails to recognize dependency and substitute variables

Update of bug #57866 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: Hi: the behavior you'r

[bug #57781] make broken on MIPS big-endian if posix_spawn() is used

Update of bug #57781 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #3: Thanks all! _

[bug #57692] Parallel make doesn't work well with grouped targets

Update of bug #57692 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: The entire point of gr

[bug #57672] Hard to read type-o

Update of bug #57672 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: This is the GNU make p

[bug #57625] Shell builtins not working unless explicitly set SHELL to "sh"

Update of bug #57625 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #46193] Discussion of system crash behaviours

Update of bug #46193 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #55863] '-load' directive adds its object to the target list if unsuccessful

Update of bug #55863 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #3: I don't understand thi

[bug #49262] Update match-anything rule documentation

Update of bug #49262 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #57602] read.c file has double slash comment in 2344 string

Update of bug #57602 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM _

[bug #57575] --load-average changes order or jobs

Follow-up Comment #3, bug #57575 (project make): All that means is that it's harder to get exactly the right number of jobs to run in parallel without -l. The -l option doesn't change anything except add an extra test that make checks to see if it can run a job. So instead of "I have a job to ru

[bug #57575] --load-average changes order or jobs

Update of bug #57575 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: It's not the -l option

[bug #42125] Explicit rules do not support multiple targets

Update of bug #42125 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #41273] Directory cache causes issues with wildcard, etc.

Follow-up Comment #3, bug #41273 (project make): Duplicated by #57102 ___ Reply to this item at: ___ Message sent via Savannah https://savannah.gnu.o

[bug #57102] $(wildcard) caches the result, and returns incorrect results on subsequent calls with the same parameter

Update of bug #57102 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #1: This is a duplicate of

[bug #29104] Directory Search for Link Libraries doesn't work in implicit rules

Follow-up Comment #4, bug #29104 (project make): Duplicated by bug #56732 ___ Reply to this item at: ___ Message sent via Savannah https://savannah.g

[bug #56732] VPATH doesn't work with pattern rules

Update of bug #56732 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #4: This is a duplicate of

[bug #43414] Perl test script bugs/enhancements

Update of bug #43414 (project make): Item Group: Bug => Enhancement ___ Reply to this item at: ___ Messa

[bug #53152] Intermittent timeout running regression test features/output_sync

Follow-up Comment #4, bug #53152 (project make): I see the issue; thanks for the explanation Michael. In some ways this is more of a test artifact than something likely to appear in a real makefile, although I think it really is a bug in make's logic. In a real makefile it's highly unlikely that

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

Update of bug #57022 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #56655] Pattern rule fails when filename contains a space

Update of bug #56655 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #30829] vpath conflict with file mention in makefile vs file on disk

Update of bug #30829 (project make): Item Group:None => Bug ___ Reply to this item at: ___ Messa

[bug #41246] Allow to switch shell batch mode at runtime instead of build time

Update of bug #41246 (project make): Item Group:None => Enhancement ___ Reply to this item at: ___ Messa

[bug #54429] make can block after being killed (3)

Update of bug #54429 (project make): Item Group:None => Bug ___ Reply to this item at: ___ Messa

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

Update of bug #56301 (project make): Item Group:None => Bug ___ Reply to this item at: ___ Messa

[bug #53879] Support for .ONESHELL target on Windows and DOS platforms

Update of bug #53879 (project make): Item Group: Bug => Enhancement ___ Reply to this item at: ___ Messa

[bug #57152] Fix WINDOWS32 gcc build

Follow-up Comment #5, bug #57152 (project make): I don't have access to any Windows systems with any version of either cygwin or mingw installed (well, I have Git for Windows installed and it provides some aspects of mingw I believe), nor clang or GCC for windows: all I can test is the simple nati

[bug #54161] Expansion of $$* is incorrect

Update of bug #54161 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #57152] Fix WINDOWS32 gcc build

Follow-up Comment #3, bug #57152 (project make): Oh that's good to know. I used __MINGW32__ which I guess is not right. According to my research I guess I should use __MINGW64__ instead. ___ Reply to this item at:

[bug #14771] Make sometimes failes to validate targets that are already compiled

Update of bug #14771 (project make): Open/Closed:Open => Closed ___ Follow-up Comment #1: Sorry but I can't decipher the issue there. If someone can come up with a repro case, on a more mo

[bug #57178] Allow $(shell $(MAKE) ...) to participate in jobserver

Update of bug #57178 (project make): Item Group: Bug => Enhancement Summary: Job server not invoked in initial pass => Allow $(shell $(MAKE) ...) to participate in jobserver ___

[bug #57151] Fix WINDOWS32 MSVS build

Update of bug #57151 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM _

[bug #57152] Fix WINDOWS32 gcc build

Update of bug #57152 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM _

[bug #57365] Makefile autocomplete is puzzled with lines starting with spaces

Update of bug #57365 (project make): Open/Closed:Open => Closed ___ Follow-up Comment #1: Bash command-line completion for makefiles is handled by some other package: it's not provided by G

[bug #56449] job.c (construct_command_argv_internal): Must use shell if '%' character is present in recipe line

Update of bug #56449 (project make): Fixed Release: SCM => None ___ Reply to this item at: ___ Messa

[bug #57014] make-4.2.91 segfaults under Solaris 10 when many files are involved

Update of bug #57014 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #4: Thanks for the investi

[bug #57014] make-4.2.91 segfaults under Solaris 10 when many files are involved

Follow-up Comment #1, bug #57014 (project make): Thanks for reporting. That seems bad, but unfortunately there's nothing I can do with this report as-is. It doesn't fail on any system I have access to, so the only way it will be addressed, other than by accident, is if someone can provide detail

[bug #40657] Suffix rules and prerequisites

Follow-up Comment #3, bug #40657 (project make): I guess I'm not quite sure what you're asking for here: what kind of diagnostic do you mean? In general I don't like to emit diagnostics for things which are actually legal and defined makefile syntax, even if they're unlikely to be what the author

[bug #56914] Most output missing when building with --output-sync

Update of bug #56914 (project make): Status:None => Works for me Open/Closed:Open => Closed ___ Follow-up Comment #2: I'm going to close thi

[bug #56918] endless loop under Darwin if recipe is non_existent_program

Update of bug #56918 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM Triage Status:

[bug #56918] endless loop under Darwin if recipe is non_existent_program

Update of bug #56918 (project make): Assigned to:None => psmith ___ Follow-up Comment #1: Hm I can reproduce on GNU/Linux as well. It seems we get into a state where we have no children bu

[bug #56914] Most output missing when building with --output-sync

Follow-up Comment #1, bug #56914 (project make): There's not nearly enough information here to do anything with this issue. Which output-sync mode did you choose? What operating system are you building on? Is this behavior consistent? I use --output-sync=target all day every day (I have it set

[bug #56895] Cannot build make due to compiler warnings/failures

Update of bug #56895 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #56895] Cannot build make due to compiler warnings/failures

Follow-up Comment #2, bug #56895 (project make): I think the fall through in read.c is incorrect. I think this code is broken when HAVE_DOS_PATHS is set. I can't see any justification for falling through into the variable case if we find a ":" in a drive spec. If we detect a ":" in a drive spec

[bug #56895] Cannot build make due to compiler warnings/failures

Follow-up Comment #1, bug #56895 (project make): The failure for find_in_given_path() is because one version of that function was pushed to gnulib, then I pushed my changes to use it to GNU make, then another version of that function with a different calling signature was pushed to gnulib so if yo

[bug #56892] toxic combination of -include and match-anything rules

Update of bug #56892 (project make): Item Group: Bug => Enhancement ___ Reply to this item at: ___ Messa

[bug #56892] toxic combination of -include and match-anything rules

Follow-up Comment #3, bug #56892 (project make): I can think of one way to address these types of issues that might not be too impactful: Make knows both how deep inside a recursion it is (via MAKELEVEL) and also how many times its re-exec'd itself (via MAKE_RESTARTS). It could check to see if e

[bug #56892] toxic combination of -include and match-anything rules

Follow-up Comment #1, bug #56892 (project make): It is definitely not the case that we can ignore -include if the makefile doesn't exist. In fact until recently, virtually every makefile that needed to be rebuilt would be included with "-include", because otherwise you'd get a warning that the fi

[bug #56834] PATH not honored when --disable-posix-spawn is not used

Update of bug #56834 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #56875] subst failure for "$" character

Update of bug #56875 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: Thanks Andreas. Closi

[bug #49014] Zombies in parallel builds with pselect code

Update of bug #49014 (project make): Open/Closed:Open => Closed ___ Follow-up Comment #23: I'm re-closing this :). The problem Kurt reports is a duplicate of bug #51400. It was fixed with

[bug #49014] Zombies in parallel builds with pselect code

Update of bug #49014 (project make): Open/Closed: Closed => Open ___ Follow-up Comment #22: I'll reopen this so I don't lose track of it. For the next release I wanted to completely rewrite

[bug #56449] job.c (construct_command_argv_internal): Must use shell if '%' character is present in recipe line

Follow-up Comment #5, bug #56449 (project make): Sorry, I think there's some confusion. All this patch does is detect if we see a % in the command line and if so we do not take the fast path: instead we take the slow path and invoke command.com. So we're not trying to handle environment variable

[bug #56449] job.c (construct_command_argv_internal): Must use shell if '%' character is present in recipe line

Follow-up Comment #3, bug #56449 (project make): I wasn't thinking about % as an escape character so much as a variable introduction character. But I keep forgetting that variable expansion in Windows works very differently than in POSIX. I was assuming that: all: ; argv1 %Path% would need t

[bug #56701] Do not allow -j without a number

Follow-up Comment #3, bug #56701 (project make): First, "$(nproc)" is not easy to obtain in a portable manner; this has been asked many times before. Second, I'm not sure if using -l $(nproc) is the right way to handle this. It's still a change in behavior, just one that's more obscure. Let's s

[bug #56749] Any chance to make new release?

Update of bug #56749 (project make): Open/Closed:Open => Closed ___ Follow-up Comment #3: A new release candidate has been published. _

[bug #56701] Do not allow -j without a number

Update of bug #56701 (project make): Item Group: Bug => Enhancement ___ Follow-up Comment #1: Actually -j without a number is useful: it's used in conjunction with the -l option to allow parall

[bug #56449] job.c (construct_command_argv_internal): Must use shell if '%' character is present in recipe line

Update of bug #56449 (project make): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #1: Thanks for the bug rep

[bug #56019] Decreased parallelization vs. Make 3.82

Update of bug #56019 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #3: Thanks for verifying.

[bug #56420] Unclear wording or missing word

Update of bug #56420 (project make): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #2: Thanks for this report

[bug #56484] [RFE] compile modified files first

Follow-up Comment #3, bug #56484 (project make): The POSIX standard requires that prerequisites are processed in order; it says: > The make utility shall treat all prerequisites as targets themselves and recursively ensure that they are up-to-date, processing them in the order in which they appea

[bug #56778] 'define' ... 'endef' serializes sub-make invocations

Update of bug #56778 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: Questions like this ab

[bug #56764] Different behavior of printf command executed from Makefile and from shell.

Update of bug #56764 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: The problem is you're

[bug #56667] Bad sorting with asttable if nan is present (GNU version 0.9.57-0e349)

Update of bug #56667 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: This bug is filed agai

[bug #39310] Regression in glob-handling from 3.81, can't use a stem and a glob in the same dependency

Follow-up Comment #3, bug #39310 (project make): GNU make has never really handled filenames with spaces very well. However please file a new bug in Savannah (preferably with an example showing the problem) rather than commenting on already-closed bugs. You can refer to this bug in the new one,

[bug #28456] Expansion of $$< is incorrect

Follow-up Comment #8, bug #28456 (project make): Thanks for that fix Mike. I've applied it. I rewrote the tests somewhat to be a bit more specific. As for the rest of these problems, there are real issues here which are not easily solved. The only way to make something like this: foo: bar $$

[bug #56422] How to find the number of rules in GMAKE

Update of bug #56422 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: Make doesn't know how

[bug #54740] .SILENT: propagates into recursive makes

Update of bug #54740 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #54980] buffer overread in jhash_string

Update of bug #54980 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #54549] Segfault caused by makefile in make version 4.2.1

Update of bug #54549 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #46013] Command overrides added to MAKEOVERRIDES are lost if there were no overrides in the command line

Update of bug #46013 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM _

[bug #54116] Extend documentation for space-free line continuation techniques

Update of bug #54116 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM _

[bug #51974] call on multiline (define/endef) behavior not well-documented

Update of bug #51974 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM _

[bug #52697] Don't start parallel jobs if memory is low

Update of bug #52697 (project make): Summary: More varieties to -j switch => Don't start parallel jobs if memory is low ___ Reply to this item at: ___

[bug #55137] $(file …) is executed too early when used in recipe

Update of bug #55137 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: It's always been the c

[bug #55088] out-of-bounds read at arscan.c::720

Update of bug #55088 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #1: A number of updates fo

[bug #55719] Variables containing hyphens are not exported

Update of bug #55719 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: The variable "foo-bar"

[bug #55720] Make cannot execute shell-builtin commands in recipe

Update of bug #55720 (project make): Item Group:None => Enhancement Status:None => Fixed Assigned to:None => psmith Open/Closed:

[bug #55863] '-load' directive adds its object to the target list if unsuccessful

Follow-up Comment #2, bug #55863 (project make): Can you explain what you mean by "the target list"? I don't know what that means. Can you provide a repro case? ___ Reply to this item at: ___

[bug #55532] Missing prerequisites are not included in $? if .SECONDARY is present

Update of bug #55532 (project make): Status: Not A Bug => None Open/Closed: Closed => Open ___ Reply to this item at:

[bug #55532] Missing prerequisites are not included in $? if .SECONDARY is present

Update of bug #55532 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #3: The issue here is that

[bug #55560] .SECONDEXPANSION and eval in target-specific prerequisite lists

Update of bug #55560 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #4: I'm afraid I can't rea

[bug #55532] Missing prerequisites are not included in $? if .SECONDARY is present

Update of bug #55532 (project make): Summary: Missing prerequisites are not included in $^ if .SECONDARY is present => Missing prerequisites are not included in $? if .SECONDARY is present ___ Follow-up Comment #2: It's ex

[bug #55691] New make release plan

Update of bug #55691 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: Please discuss things

[bug #55243] Request for a way to indicate that the same recipe execution produces several targets

Update of bug #55243 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #1: Duplicate of bug #8297

[bug #56025] .RECIPEPREFIX doesn't parse line continuations inside function calls

Follow-up Comment #2, bug #56025 (project make): I agree that this is not right. The handling of the prefix character needs a bit of work. However, I should say that I intended the prefix character to ONLY be used to introduce the initial line of a recipe. Maybe that intention needs some rethou

[bug #55944] make-4.2 arm64 w10 test

Update of bug #55944 (project make): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #1: Sorry, but there's no

[bug #56206] ifndef false positive for exported variable

Follow-up Comment #2, bug #56206 (project make): Somehow my previous comment was truncated (I do so HATE Savannah markup :( ): There is another assignment operator for variables, ‘?=’. This is called a conditional variable assignment operator, because it only has an effect if the variable is not

[bug #56206] ifndef false positive for exported variable

Update of bug #56206 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: This behavior is corre

[bug #8297] Allow multiple targets to be built from a single explicit rule recipe invocation

Update of bug #8297 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #42288] limit parallelism based on available memory

Follow-up Comment #3, bug #42288 (project make): Limiting jobs based on available memory, like -l but for memory, would be significantly less complicated than the original request of expressing how much memory a recipe might consume and having make defer running recipes that are too large and inst

[bug #56064] bash + .ONESHELL breaks when .SHELLFLAGS is set

Update of bug #56064 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Reply to this item at:

<    2   3   4   5   6   7   8   9   10   11   >