[bug #17572] Using Windows pathnames fail

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

Re: Report this to bug-make@gnu.org

Thanks; this will be fixed in the next version of GNU make. Cheers! -- --- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesl

[bug #17665] Content of computed variable name not considered as dependency

Update of bug #17665 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: > I do not know if th

[bug #17880] Manual needs example for order-only prerequisites

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

[bug #16304] Small update needed to Section 3.5

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

[bug #16468] A typo on page 21 of the make manual version 3.81 edition 0.70

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

[bug #16577] commas inside inline-comments are parsed

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

[bug #16652] typo in make(1) manpage in cvs / 3.81

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

[bug #17701] Description of .NOTPARALLEL is incorrect

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

[bug #17880] Manual needs example for order-only prerequisites

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

[bug #17883] target-specific variables prevent builtin rules

Update of bug #17883 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: As Philip points out,

[bug #16051] Non-existent prerequisites are not included in $?

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

Re: typos

On Sunday, 6 August, Ralf Wildenhues ([EMAIL PROTECTED]) wrote: > I noticed a couple of typos in the make manual. I installed fixes for these. Thanks! -- --- Paul D. Smith <[EMAIL PROTECTED]> Find

[bug #16698] REGRESSION: make check fails with LANG set

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

[bug #17740] make fails without any message

Follow-up Comment #3, bug #17740 (project make): Someone who sees this problem will need to either provide a reproducible test case, or a description clear enough to allow me to create one. Based on the information in this bug I tried this: include foo.d foo.d: foo.x ; : cp $< $@ all: ; :

[bug #18116] filter_out functions seems to always return an empty result

Update of bug #18116 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: As Philip says, the p

[bug #18139] make chooses wrong pattern rule

Follow-up Comment #2, bug #18139 (project make): It's not true that this is a Windows-only thing. I reproduced it on my Linux system. ___ Reply to this item at: ___

[bug #18139] make chooses wrong pattern rule

Follow-up Comment #5, bug #18139 (project make): Boris, I don't see why %.o being intermediate makes a difference. Make can and does chain implicit rules. I re-read the section on chaining and I don't see anything that would contradict the basic premise of chaining, which is that the length of

[bug #18124] make-3.81 isn't parallel build safe

Follow-up Comment #2, bug #18124 (project make): FYI, there's some conversation on this bug over in the Red Hat Bugzilla database. I don't understand the bug and the patch doesn't enlighten me, so I'm asking for some more detail. ___ Repl

[bug #18139] make chooses wrong pattern rule

Follow-up Comment #8, bug #18139 (project make): Hm. Boris, is that the way it's always worked or is it something we changed recently? According to the docs as far as I can tell there's no such distinction between rules that require intermediates and those that don't. In fact, it seems pretty

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

Follow-up Comment #10, bug #15919 (project make): Hi Icarus. The easiest way to get a patch into GNU make is to attach it to the bug report and/or create a separate patch item (the first is preferred). We'll review it and apply it as-is or else discuss it with you if necessary. Also, if the pa

[bug #18173] Modification of search pattern for default make rule files

Update of bug #18173 (project make): Open/Closed:Open => Closed ___ Follow-up Comment #1: Heh. Cute :-) Feel free to use some other software to do your builds. We won't be offended. We

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

Follow-up Comment #12, bug #15919 (project make): Thanks Icarus; that's great. Especially new testcases: that always helps. One thing: in general I like to have the ChangeLog entry describe what the change does and how it fixes things, rather than just describing the symptoms of the bug. Do yo

[bug #18312] $(eval) within conditionals causes make to stop with syntax error

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

[bug #17881] Better documentation of make rules

Follow-up Comment #2, bug #17881 (project make): Actually, make _does_ guarantee that rules will be processed in left-to-right order. If you never use parallelism, you can be sure your rules will always run in that order. If you do use parallelism, though, obviously more than one of these rules

[bug #18369] pattern rules don't work with spaces in filenames

Update of bug #18369 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #1: The short answer is,

[bug #18335] Addition of $(math ...) functions

Follow-up Comment #3, bug #18335 (project make): My intention was to leave the math functions to the Guile integration. I'm open to discussion on this point. If we do decide to create a built-in math section for GNU make, I wouldn't want to see it using the kind of Lisp-like syntax described by

[bug #18396] stack size setrlimit call interacts badly with Solaris/x86 kernel bug

Update of bug #18396 (project make): Item Group: Bug => Enhancement ___ Follow-up Comment #1: > If 'make' needs to allocate a large amount (megabytes) of data, > it would be better to do so on

[bug #18396] stack size setrlimit call interacts badly with Solaris/x86 kernel bug

Follow-up Comment #2, bug #18396 (project make): I wrote: > if large amounts of memory are needed they are allocated on the stack Of course I meant on the _heap_ :-/. ___ Reply to this item at: _

[bug #18517] Compilation error in find_directory() in dir.c on Windows platforms

Update of bug #18517 (project make): Status:None => Later Open/Closed:Open => Closed ___ Follow-up Comment #1: Hi all. The make sou

[bug #18680] fix for bug#2846 does not work as expected, still hang sometimes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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

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

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

[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 #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 #51400] SIGCHLD gets unblocked

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

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

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

[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, n

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

[bug #51973] variable value set by target-specific assignment not available to reference in multi-line variable definition

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

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

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

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

[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 #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 #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 #52912] minor bug in GNU make's own Makefile under .ONESHELL

Follow-up Comment #1, bug #52912 (project make): Unfortunately, Makefile.in is generated by automake and that rule is part of automake's autogenerated content, it's not part of GNU make, so there's not much we can do about it (at least, not easily). I think that your use-case is going to cause lo

[bug #52912] minor bug in GNU make's own Makefile under .ONESHELL

Update of bug #52912 (project make): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #3: I'm saying that if you

[bug #52922] -Otarget does not function properly and errors on FreeBSD, with stdout to a pipe

Follow-up Comment #1, bug #52922 (project make): Yes, I'm aware of this as I've seen it happen on MacOS systems myself. Thanks for filing the bug, as I never got around to it. I've been considering different ways to address the issue including using a lock file on systems where locking of pipes

[bug #53201] Target runs incorrect command when shebang line exceeds kernel limit

Follow-up Comment #4, bug #53201 (project make): I don't understand the issue being reported. It would be greatly illuminating if you could provide an example of the extra-long shebang line for me to examine. I've tried for a bit to reproduce the problem and cannot. It's not clear from your rep

[bug #53597] Cross-compilation fails on GNU/Linux with GNU libc 2.27

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

[bug #53465] Outdated GNU glob handles d_type incorrectly for GLOB_ONLYDIR

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

[bug #54395] Regression in validation of GNU-style long names in archives

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

[bug #52642] Newer MSVC has

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

[bug #52330] make check fails in functions/file because of translated messages

Update of bug #52330 (project make): Status:None => Fixed Open/Closed:Open => Closed Operating System:None => POSIX-Based Fixed Release:

[bug #53201] Target runs incorrect command when shebang line exceeds kernel limit

Update of bug #53201 (project make): Status:None => Works for me Open/Closed:Open => Closed ___ Follow-up Comment #5: I re-examined the code

[bug #52076] wildcard/glob should be sorted

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

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

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

[bug #54233] Infinite loop w/ -j2 & multiple pattern rules

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

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

Follow-up Comment #3, bug #53879 (project make): Thanks for the patch it would be great to have this work on Windows. I agree with Eli that as it is the patch is large enough to require paperwork. If you're interested in that please send me email . These days it can all be done electronically i

<    15   16   17   18   19   20   21   22   23   24   >