[bug #19448] Re-exec after include file rebuild is more dependent on filesystem timestamps than strictly necessary.

Update of bug #19448 (project make): Item Group:None = Enhancement ___ Follow-up Comment #7: Switching to an enhancement request. ___

[bug #16473] Improper typedef of bsd_signal

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

[bug #16469] typo in error message

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

[bug #16401] Signal received during wait(2) call may cause make to fail

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

[bug #17245] $(notdir foo/) should return . instead of blank

Update of bug #17245 (project make): Item Group: Bug = Enhancement ___ Follow-up Comment #2: The notdir function has been around for so many years now I'm not sure how reasonable it is to

[bug #17521] target-specific variables inluding semicolon

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

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

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

[bug #17752] target fails depending on order of prereqs

Follow-up Comment #1, bug #17752 (project make): Hm. I looked at this. It looks like a bug to me. I traced it down to a change by BorisK on 21 Sep 2004: * implicit.c (pattern_search): When considering an implicit rule's prerequisite check that it is actually a target rather

[bug #19108] Pattern rules with multiple target patterns do not honor the dependencies of all targets correctly

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

[bug #17752] target fails depending on order of prereqs

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

[bug #21670] implicit rule ignored for prerequisite that is produced by .DEFAULT

Update of bug #21670 (project make): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #2: I believe this is a

[bug #17752] target fails depending on order of prereqs

Follow-up Comment #3, bug #17752 (project make): See also bug #21670 for another instance of this. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17752 ___ Message sent via/by

[bug #18305] target specific variables with conditional assignments

Update of bug #18305 (project make): Item Group: Bug = Enhancement ___ Follow-up Comment #1: Hm. The way conditional variables work is that the conditionality of the variable is determined

[bug #18139] make chooses wrong pattern rule

Update of bug #18139 (project make): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #10: I believe this is a

[bug #17752] target fails depending on order of prereqs

Follow-up Comment #4, bug #17752 (project make): See bug #18139 for another instance of this. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17752 ___ Message sent via/by

[bug #17825] $? is not filled in if make --always-make is used

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

[bug #14617] wildcard function produces incorrect results because of cache

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

[bug #443] $(wildcard) function uses directory cache: gives incorrect results sometimes

Follow-up Comment #2, bug #443 (project make): Bug #14617 is closed as a duplicate of this bug. ___ Reply to this item at: http://savannah.gnu.org/bugs/?443 ___ Message sent via/by

[bug #18123] wilcard function fails (...)*/ expansion

Follow-up Comment #1, bug #18123 (project make): GNU make uses the libc glob(3) function to expand wildcard expressions. I've checked with GNU libc and the behavior you're seeing is actually what glob(3) is returning to us. Possibly other libc's will have different behavior. I've filed a bug

[bug #17752] target fails depending on order of prereqs

Follow-up Comment #5, bug #17752 (project make): See bug #20006 as another instance ___ Reply to this item at: http://savannah.gnu.org/bugs/?17752 ___ Message sent via/by Savannah

[bug #18435] no rule to make target whose name contains close parenthesis

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

[bug #13401] MAKEFILES indirect include incorrectly supplies default goal

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

[bug #13976] Regression in :: deps handling between V3.76 and V3.80

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

[bug #18622] regression cannot turn off implicit rules for %.c and %.tex in 3.81

Follow-up Comment #2, bug #18622 (project make): Ouch. This is a result of the secondary expansion feature. The problem is that we defer the tokenization of dependencies until the snap_deps() step, when all the makefiles have been read in. This means that when we try to override the pattern

[bug #13529] Incorrect circular dependancy

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

[bug #19226] False warning about a circular dependency

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

[bug #21984] make detects circular dependency when there is none

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

[bug #15176] .SECONDARY changes build order

Update of bug #15176 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #2: This is indeed not a

[bug #13554] Target-specific variable values inherited by sub-targets

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

[bug #17206] make -d .PHONY output is misleading

Update of bug #17206 (project make): Item Group: Bug = Enhancement ___ Reply to this item at: http://savannah.gnu.org/bugs/?17206 ___ Message

[bug #18123] wildcard function fails (...)*/ expansion

Update of bug #18123 (project make): Summary: wilcard function fails (...)*/ expansion = wildcard function fails (...)*/ expansion ___ Reply to this item at: http://savannah.gnu.org/bugs/?18123

[bug #26863] $(wildcard x*/) returns non-directories?

Update of bug #26863 (project make): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #1: Thanks for the report.

[bug #21771] make 3.81 is deleting intermediate files in a wrong way

Update of bug #21771 (project make): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #1: This appears to me to

[bug #23960] Crash when MAKEFILE_LIST becomes too long.

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

[bug #27143] Crash in a pair of mutually recursive macros

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

[bug #27047] Difficulties defining prerequisites for pattern targets.

Follow-up Comment #4, bug #27047 (project make): The failure you are reporting is actually documented behavior; the documentation for target-specific variables says: As with automatic variables, these values are only available within the context of a target's command script (and in other

[bug #27093] implicit rule documentation slightly wrong

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

[bug #24509] doc for wildcard expansion in commands could be clearer

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

[bug #18963] -include suppressing errors for too long?

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

[bug #15110] Confusing failure message for generate dependencies with 3.81beta3

Follow-up Comment #6, bug #15110 (project make): See also bug #25493 for another example of this ___ Reply to this item at: http://savannah.gnu.org/bugs/?15110 ___ Message sent via/by

[bug #26887] intermediate files declared INTERMEDIATE are made PRECIOUS

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

[bug #27437] Problems with make in a directory with present Makefiles. make does not function.

Update of bug #27437 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #1: There is little we can

[bug #27437] Problems with make in a directory with present Makefiles. make does not function.

Follow-up Comment #5, bug #27437 (project make): As Philip suggested on the mailing list (which, as I already mentioned, is the RIGHT place to ask these questions and NOT in the bug tracker), you should read the README and/or INSTALL files that come with your software package. Apparently the

[bug #12124] Make does not allow $(eval) of new targets inside command scripts

Update of bug #12124 (project make): Triage Status:None = Major Effort ___ Reply to this item at: http://savannah.gnu.org/bugs/?12124 ___ Message

[bug #27495] echo behaves different in pipe for /bin/sh symlinked to dash

Update of bug #27495 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #1: Basically what you're

[bug #27497] Later double-colon rules don't fire if earlier ones think target is up to date

Update of bug #27497 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #1: Make is behaving

[bug #16476] WINDOWS32 vs. HAVE_ANSI_COMPILER macros

Update of bug #16476 (project make): Operating System: Any = MS Windows Summary: Inconsistent function macros - again = WINDOWS32 vs. HAVE_ANSI_COMPILER macros ___ Follow-up

[bug #102] Make prints an incorrect error for missing includes

Update of bug #102 (project make): Triage Status:None = Verified ___ Follow-up Comment #8: Added a test for this to the test suite (add -all to see it).

[bug #26864] make -j2 fails to rebuild intermediate file

Update of bug #26864 (project make): Triage Status: Medium Effort = Verified ___ Follow-up Comment #2: I added a test for this into the test suite. I did some back-tracking and this bug was introduced

[bug #22531] Make 3.81 May Incorrectly Regard Object Dependencies as Complete

Update of bug #22531 (project make): Status:None = Fixed Open/Closed:Open = Closed Fixed Release:None = CVS

[bug #2884] Source file not found in vpath when implicit rule triggered by target specified with an absolute path

Follow-up Comment #2, bug #2884 (project make): This bug seems to be corrupted; it's not showing up in my lists anywhere. Maybe because of the Invalid User ID stuff in the Submitted By field? I do have some info about this so I'll try to re-attach the tar file. Note that the tar file I have

[bug #15182] Make uses too much memory

Update of bug #15182 (project make): Status:None = Fixed Open/Closed:Open = Closed Fixed Release:None = CVS

[bug #27609] Stupid inference rule for yacc files can clobber C sources!

Follow-up Comment #1, bug #27609 (project make): This is how the default rule for building YACC files in GNU make has always been, for 20-odd years. From the GNU make manual section Catalog of Rules: Yacc for C programs n.c is made automatically from n.y by running Yacc with the command

[bug #27714] expansion of $(shell) in target forces serialization of targets

Follow-up Comment #5, bug #27714 (project make): Hrm. The only way this could be fixed would be to make the $(shell ...) function a true make job, so that it takes a job token, can run in the background asynchronously, and is basically handled as an anonymous recipe line that is run before the

[bug #27714] expansion of $(shell) in target forces serialization of targets

Follow-up Comment #7, bug #27714 (project make): I'm surprised you say you can do this with BSD make; I'm not aware that BSD make has any feature like the $(shell ...) function, that can appear inside a recipe. What syntax do you use for this in BSD make? We can't expand the recipe in a forked

[bug #27591] $(wildcard) bug in latest CVS. Worked OK in 3.81 stable release.

Update of bug #27591 (project make): Operating System: MS Windows = Any Triage Status:None = Verified ___ Follow-up Comment #3: I just checked and I

[bug #28092] $(shell false) should break build

Update of bug #28092 (project make): Item Group:None = Enhancement ___ Follow-up Comment #1: There's no way $(shell ...) failing can or should cause make to stop. There are many legitimate

[bug #28126] bug with Windows interface: echo. in command only works when redirected

Update of bug #28126 (project make): Operating System:None = MS Windows ___ Reply to this item at: http://savannah.gnu.org/bugs/?28126 ___ Message

[bug #22923] option to prevent interspersed output in parallel builds

Follow-up Comment #6, bug #22923 (project make): I don't really see the difference between comment #5 and the original description. I've addressed why this is hard to do in comment #2. ___ Reply to this item at:

[bug #29286] japanese mistranslation fix

Update of bug #29286 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #1: Thanks for the report.

[bug #29403] Make does not resolve backslashes

Update of bug #29403 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #1: The new behavior is

[bug #29814] Library search feature should be configurable for multilib systems

Follow-up Comment #2, bug #29814 (project make): Make will use VPATH (or vpath) for library search as well. So, on a multilib system, you can add: vpath lib% /...whatever... to specify where to look for libraries, for example. ___

[bug #29885] MAKEFLAGS doen't pass commandline varaibles to sub-make

Follow-up Comment #1, bug #29885 (project make): There is no makefile attached to this. However, everything works as I expect so I suspect there's a problem with your makefile. Example: tmp$ cat x2.mk recurse: ; $(MAKE) -f $(MAKEFILE_LIST) show show:; : $(MAKEFLAGS) tmp$ make -f x2.mk

[bug #29885] MAKEFLAGS doen't pass commandline varaibles to sub-make

Update of bug #29885 (project make): Status:None = Works for me Open/Closed:Open = Closed ___ Reply to this item at:

[bug #19108] Pattern rules with multiple target patterns do not honor the dependencies of all targets correctly

Follow-up Comment #7, bug #19108 (project make): This problem (in comment #6 ) is not related to this bug in any way. Please ask your question on one of the mailing lists such as help-m...@gnu.org ___ Reply to this item at:

[bug #30105] Recipes defined for special targets like .SUFFIXES are silently ignored: make should warn about them

Update of bug #30105 (project make): Item Group: Bug = Enhancement Triage Status:None = Small Effort Summary: Variables set immediately after .SUFFIXES: ; are not set when leading tabs are

[bug #30105] Recipes defined for special targets like .SUFFIXES are silently ignored: make should warn about them

Follow-up Comment #3, bug #30105 (project make): Make preprocessor lines like ifdef, etc. also do not count as stopping a recipe, of course, otherwise code like: all: ifdef DEBUG : do some debug thing else : do some non-debug thing endif would not work. I didn't mean my

[bug #29968] features/recursion test fails (probably) due to changes in getopt_long

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

[bug #29757] Target-specific variables change their flavor

Update of bug #29757 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #3: Although you may find

[bug #29253] Memory corruption error when backslash line continuation used in function call

Update of bug #29253 (project make): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #2: Thanks for the report;

[bug #29245] Bug with DOS Path in Secondary Expansion (with Fix)

Update of bug #29245 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #2: I agree with Eli: this

[bug #29244] MSVC Compatibility broken with main.c Revision 1.237 (with Proposal for Fix)

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

[bug #29448] pattern rules: % doesn't match empty string

Update of bug #29448 (project make): Item Group: Bug = Enhancement Triage Status:None = Verified ___ Follow-up Comment #1: The behavior is as

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

Update of bug #29104 (project make): Operating System: MS Windows = Any Triage Status:None = Verified ___ Follow-up Comment #3: This is a real bug.

[bug #24486] Have make print a progress report during build?

Update of bug #24486 (project make): Triage Status:None = Major Effort ___ Reply to this item at: http://savannah.gnu.org/bugs/?24486 ___ Message

[bug #27714] expansion of $(shell) in target forces serialization of targets

Update of bug #27714 (project make): Status:None = Wont Fix Open/Closed:Open = Closed ___ Follow-up Comment #10: I'm going to close

[bug #30328] Fast echo (with code proposal)

Update of bug #30328 (project make): Triage Status:None = Medium Effort ___ Follow-up Comment #1: Is it really true that this is an issue? The only echo commands that can be sped up are ones that

[bug #28525] Parens in path names do not work correctly anymore

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

[bug #28425] Literal HTML markup on webpage

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

[bug #29665] .PHONY included makefiles are rebuilt but not reread

Update of bug #29665 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #2: This is not a bug. If

[bug #28230] $(eval) does not understand multiline

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

[bug #27825] win64 fix for config.h.W32.template

Update of bug #27825 (project make): Item Group:None = Bug ___ Reply to this item at: http://savannah.gnu.org/bugs/?27825 ___ Message

[bug #20542] Regression: windows gnumake + MKS shell + Special Shell Chars

Update of bug #20542 (project make): Item Group:None = Bug ___ Reply to this item at: http://savannah.gnu.org/bugs/?20542 ___ Message

[bug #28189] SIGPIPE when gmake invoked recursively and vpath specified

Update of bug #28189 (project make): Item Group:None = Bug Triage Status:None = Verified ___ Follow-up Comment #1: In the new CVS code we

[bug #29025] problem with odd directory names with spaces and/or parentheses

Update of bug #29025 (project make): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #2: Make doesn't support

[bug #105] Parallel builds should order by slowest-first

Update of bug #105 (project make): Triage Status:None = Major Effort ___ Reply to this item at: http://savannah.gnu.org/bugs/?105 ___ Message

[bug #20067] Unescaped meta characters in makefile database outputs

Update of bug #20067 (project make): Triage Status:None = Medium Effort ___ Follow-up Comment #1: It's never been a goal that the output of make -p should be a valid makefile that can be reused

[bug #15338] make: stripping leading ./ causes flaky results

Update of bug #15338 (project make): Status:None = Duplicate Open/Closed:Open = Closed Component Version:None = 3.81

[bug #27381] wildcard function acts differently than in 3.81

Update of bug #27381 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #4: It doesn't look like

[bug #27809] several win64 fixes

Follow-up Comment #6, bug #27809 (project make): Thanks Ozkan. A few comments about the parts of the patch that are not Windows-specific. First you mention compiler warning fixes for UNIX, but none of the changes you mention fix any warnings I see on my UNIX tests (different platforms but

[bug #30340] dependency handling

Follow-up Comment #2, bug #30340 (project make): You might read: http://make.mad-scientist.net/autodep.html ___ Reply to this item at: http://savannah.gnu.org/bugs/?30340 ___ Message sent

[bug #27809] several win64 fixes

Follow-up Comment #9, bug #27809 (project make): I've applied most of the second patch. The first patch is mostly in the w32 area so maybe Eli is a better person to review it? I did have one question about the first patch: you have a change to make.h which adds an include of malloc.h, but

[bug #27825] win64 fix for config.h.W32.template

Update of bug #27825 (project make): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #3: Closed as duplicate.

[bug #27809] several win64 fixes

Follow-up Comment #12, bug #27809 (project make): It is needed earlier, otherwise line #38 of make.h provides a prototype for alloca because there is no alloca.h and AIX is not defined. OK then the other #include malloc.h should probably be removed. Thanks!

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Update of bug #30381 (project make): Item Group:None = Enhancement Component Version:None = 3.81 ___ Follow-up Comment #1: This is the documented

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #2, bug #30381 (project make): Actually my example is solved by your suggestion to use a stack of targets. However, if you imagine a pattern rule where every iteration of the rule _grows_, instead of shrinks, then a stack of targets wouldn't help. What about: %.x : %.x.x ;

[bug #27809] several win64 fixes

Update of bug #27809 (project make): Assigned to:None = eliz ___ Reply to this item at: http://savannah.gnu.org/bugs/?27809 ___ Message

[bug #30312] $(abspath ...) fails with Windows UNC path (with fix)

Update of bug #30312 (project make): Status:None = Fixed Assigned to:None = eliz ___ Reply to this item at:

[bug #27809] several win64 fixes

Update of bug #27809 (project make): Status:None = Fixed ___ Reply to this item at: http://savannah.gnu.org/bugs/?27809 ___ Message

[bug #30370] add a shorthand syntax for foreach-eval-call

Update of bug #30370 (project make): Triage Status:None = Medium Effort ___ Reply to this item at: http://savannah.gnu.org/bugs/?30370 ___ Message

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