[bug #52642] Newer MSVC has

Follow-up Comment #1, bug #52642 (project make): OK thanks for the note. I'll have VS 2017 available to test on in a week or two I believe. ___ Reply to this item at:

[bug #48274] adding -j option to MAKEFLAGS no longer works

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

[bug #52209] Support for ifeq function

Follow-up Comment #2, bug #52209 (project make): Those (ifeq, ifneq) are not functions, they're preprocessor conditionals. Only $(if ...) (and $(or ...) and $(and ...)) are functions. ___ Reply to this item at:

[bug #52076] wildcard/glob should be sorted

Follow-up Comment #10, bug #52076 (project make): The test attached here is not a good one: since you create files in the directory such that they're mostly ordered already, the sort operation doesn't need to do much work. However, I created my own test using uuidgen to create files named with

[bug #52018] suggestion: test case for glob with dangling symlink

Follow-up Comment #3, bug #52018 (project make): Hm, well, I don't have a newer glibc and I don't know how the newer glob will utilize the gl_lstat element, so I don't know exactly what the test needs to do in order to stress this. Do I just need to get the wildcard function to expand a symlink

[bug #52018] suggestion: test case for glob with dangling symlink

Follow-up Comment #2, bug #52018 (project make): Heh, I guess it's in the title and I only read the problem description :). ___ Reply to this item at:

[bug #52018] suggestion: test case for glob with dangling symlink

Follow-up Comment #1, bug #52018 (project make): Can you clarify what the usage is that is not being tested? You mean, obtaining timestamps from dangling symlinks? ___ Reply to this item at:

[bug #52017] Multiple intermediate pattern targets badly managed

Update of bug #52017 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: Your example makefile

[bug #52028] Preventing infinite recursions when make is invoked from recipes

Update of bug #52028 (project make): Open/Closed:Open => Closed ___ Follow-up Comment #1: I don't think adding a new function is appropriate for this. It's simpler, IMO, to use the

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

Update of bug #51974 (project make): Item Group: Bug => Documentation Summary: multiline (define/endef) containing target-specific assignments causes errors in /bin/sh => call on multiline (define/endef) behavior not well-documented

[bug #51972] target-specific assignments and target definitions in multi-line variable definitions not handled correctly

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

[bug #51527] Make race issue when MikTeX htlatex is used

Update of bug #51527 (project make): Status:None => Works for me Open/Closed:Open => Closed ___ Follow-up Comment #5: I'm closing this for

[bug #51591] Typographical error in manual

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

[bug #51237] Deadlock in Ctrl-C handler on Windows

Follow-up Comment #6, bug #51237 (project make): It's not the exact same problem but it's caused by the same flaw in the make code: doing lots of work in a signal handler. What I was hoping to do is change the signal handler to do nothing more than set a flag saying that the fatal signal was

[bug #51434] Document that variables are treated differently in prerequisite lists and recipes

Update of bug #51434 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: There is a section of

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

Update of bug #49014 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #17: I'm going to close

[bug #51266] "make -p" erroneously prints "+=" instead of ":="

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

[bug #51400] SIGCHLD gets unblocked

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

[bug #51014] .SHELLSTATUS not always set correctly when $(shell ...) terminated by signal

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

[bug #51237] Deadlock in Ctrl-C handler on Windows

Follow-up Comment #4, bug #51237 (project make): I would prefer this to be done differently. Sorry for the late conversation. First, we have this same type of issue in UNIX (see for example bug #50557) so I would prefer to not have a Windows-specific solution. Second, I don't see why we need a

[bug #51414] Use of multiple $$% (for .SECONDEXPANSION) causes make to misinterpret the rule as a pattern rule

Update of bug #51414 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: Actually what's

[bug #51338] Support for construction patterns by make functions

Follow-up Comment #7, bug #51338 (project make): > > it's basically a request to "please make things better". > Yes, this is also true. Well, I'm not personally interested in re-designing makefiles. The makefile syntax has a lot of problems: no one would suggest that it doesn't. However, make

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #8, bug #51309 (project make): If, for example, you can show an example of notdir adding significantly to the amount of time the make program takes. To test this I created a makefile like this: foo = ... all: ; : $(words $(foo)) where the "..." represents 6000 paths

[bug #51292] Handling make rules where prerequisites are determined by functions for specific targets lists

Follow-up Comment #8, bug #51292 (project make): > I dared to propose a software extension which can be similar to the functionality “static pattern rules”. Under which circumstances can the generic variant move into the standard functions? I don't see any need to move something like this "into

[bug #51338] Support for construction patterns by make functions

Follow-up Comment #5, bug #51338 (project make): > I suggest to give some make rule combinations (pairs, trios, …) another look. That doesn't constitute a specific design. You've provided an example of makefile syntax that works today, in your initial description. Clearly you are not satisfied

[bug #51306] Checking programming possibilities around “MAKECMDGOALS”

Follow-up Comment #3, bug #51306 (project make): You can't change the set of goals that make will build by modifying the MAKECMDGOALS variable. All you can do is query which goals it will build. ___ Reply to this item at:

[bug #51338] Support for construction patterns by make functions

Update of bug #51338 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #3: Secondary expansion

[bug #51311] Checking search retries for implicit make rules

Update of bug #51311 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #3: As pointed out on the

[bug #51306] Checking programming possibilities around “MAKECMDGOALS”

Update of bug #51306 (project make): Item Group: Bug => Documentation ___ Follow-up Comment #1: The same way you'd check for a word in any other list of words, in GNU make: sources = foo.c

[bug #51297] Better support for escaping of function parameters

Update of bug #51297 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #1: It's important to

[bug #51292] Handling make rules where prerequisites are determined by functions for specific targets lists

Follow-up Comment #5, bug #51292 (project make): Bleah, typo. Rewriting: You can easily add the suffix as part of the static pattern rule: targets ::= foo bar $(targets:=.o): %.o: %.c $(CC) -c $(CFLAGS) $< -o $@ If you want a "callback"-like setup you can already do it with eval

[bug #51292] Handling make rules where prerequisites are determined by functions for specific targets lists

Update of bug #51292 (project make): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #4: You can easily add

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #5, bug #51309 (project make): I understand what you are suggesting. But I don't see any need to add new capabilities for this when the existing features of GNU make can already give these results. The only reasons for it that I can see would be (a) you prefer to do it this

[bug #51278] Support for the specification of special build properties together with each make rule

Update of bug #51278 (project make): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #1: .SUFFIXES is an

[bug #51309] Determination of a file list from a single folder without changing the working directory

Follow-up Comment #3, bug #51309 (project make): There's no question that FOO := $(notdir $(wildcard Bau/*.txt)) is more efficient than: ~/Projekte> $(cd Bau && echo "echo $(ls *txt)") because the latter involves starting a whole new shell (two, technically) while the former is handled

[bug #51269] Reusing data from targets for prerequisites

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

[bug #51267] Improve error handling after a special command

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

[bug #51309] Determination of a file list from a single folder without changing the working directory

Update of bug #51309 (project make): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #1: The current

[bug #51190] make -n does not show exported variables

Update of bug #51190 (project make): Summary: make -n fails if export is used with recursion => make -n does not show exported variables ___ Reply to this item at:

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

Follow-up Comment #14, bug #49014 (project make): Any updates on this? Have you seen the pselect() zombie issue re-appear after applying the patch? Thanks for testing! ___ Reply to this item at:

[bug #49844] 'make -j' without explicit process count sometimes doesn't parallelize

Update of bug #49844 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: Even simpler is to

[bug #43901] Stop on error when build -include

Update of bug #43901 (project make): Open/Closed:Open => Closed ___ Follow-up Comment #1: Starting with GNU make 4.2, bug #102 has been fixed which means that you no longer need to use the

[bug #41518] Can't build make from Git repository with recent autotools

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

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

Follow-up Comment #12, bug #49014 (project make): A fix for bug #51159 has been pushed to the Git repository. I have a strong suspicion that this is the same problem we're seeing here and that fix will also fix this issue. Knowing the problem I thought I might be able to conjure a scenario to

[bug #51159] pselect jobserver stuck at read does not reap children

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

[bug #50823] MAKEFILE_LIST contains wrong file name if file name contains dollar character

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

[bug #50909] eval_makefile for $(MAKEFILES) doesn't add file name to strcache

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

[bug #13651] Make seg faults if it runs out of memory (rather than failing gracefully)

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

[bug #50304] A round bracket in the latest document of GNU Make has no match

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

[bug #50300] Set CFLAGS to “-O1” with .POSIX target

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

[bug #50648] GMake 4.2.1 --with-guile fails silently if installed Guile version is higher than 2.0

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

[bug #50902] GNU Make 4.2 -- run_make_tests.pl fails to find test_driver.pl -- Proposed solution: use FindBin

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

[bug #51167] Pattern rule with no recipe fails

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

[bug #51159] pselect jobserver stuck at read does not reap children

Follow-up Comment #2, bug #51159 (project make): This does look like a promising diagnosis. I'll look at it this weekend. ___ Reply to this item at: ___

[bug #50790] Some kind of memory corruption in error messages with gcc-6.3.0 -flto=4

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

[bug #50300] Set CFLAGS to “-O1” with .POSIX target

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

[bug #50300] Set CFLAGS to “-O1” with .POSIX target

Follow-up Comment #6, bug #50300 (project make): I have this change already queued locally along with a bunch of others. I've been away for a while on vacation but I'll try to push those to Savannah this week/weekend. ___ Reply to this

[bug #50754] Archive member rules and GNU ar's deterministic (-D) option

Update of bug #50754 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: Unfortunately there's

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

Follow-up Comment #8, bug #42125 (project make): I'm afraid I don't understand: how can a static pattern rule have multiple targets? Each pattern in the target needs to match each of the elements of the static list, so clearly you can't have multiple patterns. Unless you're saying that the

[bug #50492] configure missing / autoconf fails

Update of bug #50492 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: All of the files you

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

Follow-up Comment #5, bug #42125 (project make): I understand why you may consider it counterintuitive based on the naming, but I don't understand why you consider it unfortunate. Suppose that we made the change in the implementation that you suggest: that would mean that the targets listed in

[bug #50062] Variable needed to check that Makefile is run by GNU make?

Follow-up Comment #2, bug #50062 (project make): Similarly, the $(error ...) function and indeed functions like this themselves are features only found in GNU make... so even if you were using some other implementation of make that happened to support "ifndef" the same way GNU make did, it could

[bug #50062] Variable needed to check that Makefile is run by GNU make?

Follow-up Comment #1, bug #50062 (project make): I don't really know of any way to determine whether or not you're running a particular version of make, in a makefile portable enough that it would provide useful output if you _weren't_ using that version of make. For instance in your example:

[bug #49661] syntax anomaly with order-only prereqs and pattern rules

Update of bug #49661 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #3: I'm going to close

[bug #24487] "foo" should not be identified with "./foo" if foo is phony

Follow-up Comment #4, bug #24487 (project make): The documentation for .PHONY states ( https://www.gnu.org/software/make/manual/html_node/Phony-Targets.html ): _The implicit rule search (see Implicit Rules) is skipped for .PHONY targets. This is why declaring a target as .PHONY is good for

[bug #17230] Leading ./ is stripped from targets and prerequisites

Update of bug #17230 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #2: I don't think bug

[bug #10593] $(shell) doesn't honor export but this is undocumented?

Follow-up Comment #6, bug #10593 (project make): See also duplicate bug #35323 ___ Reply to this item at: ___ Message sent via/by Savannah

[bug #49938] fdin might be (but isn't?) clobbered by vfork

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

[bug #49935] num_mkfiles uninitialized

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

[bug #46585] variables being auto-exported to the environment if it was set in the environment

Update of bug #46585 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #3: See also duplicate

[bug #48360] Environment variable doesn't loose specialness, although redefined

Update of bug #48360 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #2: It seems this is a

[bug #43378] $(guile ...) must be coaxed to accept (or does not accept) valid guile code.

Update of bug #43378 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #5: The issue about # not

[bug #40236] include, -include and sinclude ignores failures to read the included file

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

[bug #20513] # still needs to be escaped in a function like $(shell)

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

[bug #40234] Ignored missing include in makefile causes "no makefile found" message.

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

[bug #48809] renaming --jobserver-fds to --jobserver-auth breaks jobserver interoperability

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

[bug #49865] read.c:2681: possible missing break ?

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

[bug #49114] job.c: Fixed conversion specifier.

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

[bug #45477] cygwin: regression in VPATH handling.

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

[bug #49115] read.c: Fixed invariant condition.

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

[bug #49116] w32/subproc/sub_proc.c: Fixed potential null pointer dereference.

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

[bug #49112] arscan.c: Fixed printf conversion specifier in TEST mode

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

[bug #49111] w32: Removed unused telldir() function.

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

[bug #48951] Grammar mistake in section 5.3.1

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

[bug #49773] release/archive older make manuals

Update of bug #49773 (project make): Item Group:None => Documentation ___ Follow-up Comment #1: I've had discussions before with the GNU web site folks about doing this. I'd prefer to have some

[bug #49681] Make fails to glob lib/*.{o,a}

Update of bug #49681 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: Any commands inside a

[bug #49590] wildcard no longer give sorted output in version 4.2

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

[bug #49183] Macros set in MAKEFLAGS should not be added to the environment

Follow-up Comment #3, bug #49183 (project make): The current POSIX standard is available online for free and has been for many years now: http://www.opengroup.org/onlinepubs/9699919799/ The change seems pretty innocuous to me. The number of people who set the MAKEFLAGS variable in their local

[bug #49093] ifdef checks for non-empty value, not definition

Update of bug #49093 (project make): Status:None => Works for me Open/Closed:Open => Closed ___ Follow-up Comment #2: Heh. Philip Guenther

[bug #49093] ifdef checks for non-empty value, not definition

Update of bug #49093 (project make): Item Group: Bug => Documentation Triage Status:None => Small Effort ___ Follow-up Comment #1: What the doc is

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

Follow-up Comment #6, bug #49014 (project make): It can't be implemented in userland. What pselect() does is unblock the signal, call select, then have the signal blocked again on return. The point of using pselect() is that the signal unblock/block must be atomic with the select() system call.

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

Follow-up Comment #4, bug #49014 (project make): I took a look through the code. I could to do a more comprehensive review but at first glance it looks like everything is OK: if PSELECT is enabled then we block SIGCHLD right at the start of the make process and we never unblock it except as a

[bug #48276] Better errors for accidental spaces

Follow-up Comment #1, bug #48276 (project make): I'm not that excited about this idea. The problem is that lots of makefiles indent their variables, rules, etc. For example inside "ifeq" statements, or even just to right-align variable assignments. Having warnings about changing to TAB on most

[bug #48070] "make update" fails at wget of translationproject translations

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

[bug #47995] Parallel double-colon breaks FORCE

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

[bug #48009] Increased stack rlimit is inherited by the subprocesses to make when make restarts

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

[bug #48045] gmake-4.2 breaks firefox-46.0.1 build

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

[bug #48057] make 4.2 breaks parallel builds of git, perl, dialog, xterm and probably more

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

[bug #48061] make check in targets/DELETE_ON_ERROR fails on Solaris 10

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

[bug #48060] Recipe line flags leak between targets defined in one rule

URL: Summary: Recipe line flags leak between targets defined in one rule Project: make Submitted by: psmith Submitted on: Mon 30 May 2016 05:32:13 PM EDT Severity: 3 - Normal

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