[bug #65759] handling of "-" and "--" on command line

Follow-up Comment #5, bug #65759 (group make): I looked through the code. This is explicitly handled, and ignored, with a commit message by Roland from 1995 saying only: commit 636435e5c25d39fc5d52edf936e8e7a410b31b1a Author: Roland McGrath Date: 1995-03-07 22:31:01 +

[bug #65759] handling of "-" and "--" on command line

Follow-up Comment #3, bug #65759 (group make): Yes it is a valid filename but the problem, as pointed out in the original description, is that make doesn't treat it that way. At least not all the time. It appears that the code wants to treat it as if you'd used "-f-" but it doesn't appear to

[bug #65739] Add warnings circular-dep and circular-extra-dep.

Follow-up Comment #3, bug #65739 (group make): I applied the first patch (with a few tweaks). Thanks! Let's discuss the second patch in bug #60736 instead ___ Reply to this item at:

[bug #60736] Introduce "Circular <- dependency dropped." for .EXTRA_PREREQS deps.

Follow-up Comment #6, bug #60736 (group make): I think that using a warn option is better than forcing this to always warn. But I still think that the warning makes global usage useless, and since there's no way to control warnings on a per-target basis (today) it means the warning is hard to

[bug #65759] handling of "-" and "--" on command line

Follow-up Comment #1, bug #65759 (group make): The behavior of "make --" is as expected because according to the POSIX standard, the argument *--* specifies that no files after it are to be considered options even if they begin with "-". So for example if you wanted to make a target named *-f*

[bug #65685] Submake starts its own jobserver when its recipe contains $(MAKE) $(MFLAGS)

Follow-up Comment #2, bug #65685 (group make): I'm not sure I get where the problem is coming from. The way I remember it is that if we see a valid jobserver-auth argument, we ignore the value of -j. This is so that we can keep the -j option in the value of MAKEFLAGS so that users can review

[bug #65323] Functions/shell test 22 causes ksh to crash.

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

[bug #65324] Fix crash in disable_builtins.

Update of bug #65324 (group make): Status:None => Fixed Open/Closed:Open => Closed Operating System:None => Any Fixed Release:

[bug #65536] make.texi:5449: node `Using Variables' lacks menu item for `Conditionalizing' despite being its Up target

Update of bug #65536 (group make): Item Group: Bug => Documentation Status:None => Fixed Assigned to:None => psmith Open/Closed:

[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

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

[bug #65273] Potential bug in the info function?

Update of bug #65273 (group make): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #10: I have decided, for

[bug #65600] `--silent` option should also silence `$(info ...)`

Update of bug #65600 (group make): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #10: Thanks for the

[bug #65596] Test for let function not available in .FEATURES

Update of bug #65596 (group make): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #3: As Dmitry mentions most

[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

Follow-up Comment #3, bug #65537 (group make): I see there's a new stable branch: either these are not getting announced or I missed it. Can you try applying this patch and switching to this stable branch and see if it is fixed: diff --git a/bootstrap.conf b/bootstrap.conf index

[bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

Follow-up Comment #1, bug #65537 (group make): This is an issue with gnulib, not GNU Make, where that macro is defined. Are you using the latest HEAD of the stable-202307 branch of gnulib? It should be SHA 2f47ff2e115712 If so then we need to discuss on the gnulib mailing list.

[bug #65536] make.texi:5449: node `Using Variables' lacks menu item for `Conditionalizing' despite being its Up target

Follow-up Comment #1, bug #65536 (group make): Hrm why don't I see this? Martin can you let me know what version of makeinfo you are using? ___ Reply to this item at:

[bug #65533] gmake-4.4.1 has a performance regression: at least the nwchem project now builds much slower

Follow-up Comment #4, bug #65533 (group make): I cloned the nwchem git repository and my suspicions were correct. I see many, many instances of recursive variable assignment using $(shell ...) syntax, such as: src/nwc_columbus/sifs/GNUmakefile 38:ALLF = $(filter-out ./sifs_stubs.F, $(shell find

[bug #65533] gmake-4.4.1 has a performance regression: at least the nwchem project now builds much slower

Follow-up Comment #1, bug #65533 (group make): Since I don't have any idea what the "nwchem" project is or how its makefiles work and you haven't provided any short examples, I can't say for sure. However, it's almost 100% sure that the problem is that the project's makefiles use a lot of

[bug #65448] $(intcmp) problems with negative integers

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

[bug #64085] -e passed to shell in POSIX mode with -i or .IGNORE

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

[bug #65359] submake might will lose variable values if their names contain special char

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

[bug #65268] Reset O_APPEND mode for stdout and stderr

Update of bug #65268 (group make): Item Group:None => Bug Status:None => Fixed Assigned to:None => psmith Open/Closed:

[bug #65438] Sort print-targets output.

Follow-up Comment #4, bug #65438 (group make): Regarding the hashing vs. endianness, I don't know. The hash.{c,h} implementation we have was taken, basically verbatim, from the GNU idutils program. Regarding sorting, doesn't this basically mean just using strcmp (or a small wrapper around it)

[bug #54854] multi-target rules invoked too often with -j2

Follow-up Comment #9, bug #54854 (group make): Hopefully it will solve it! That would be nice. Cheers! ___ Reply to this item at: ___ Message sent

[bug #54854] multi-target rules invoked too often with -j2

Follow-up Comment #7, bug #54854 (group make): If you can rely on having GNU Make 4.3 or better, you can use grouped explicit targets to get the same behavior make provides to pattern rules, with explicit rules: https://www.gnu.org/software/make/manual/html_node/Multiple-Targets.html If you

[bug #54854] multi-target rules invoked too often with -j2

Follow-up Comment #5, bug #54854 (group make): Definitely there are a lot of valid uses. Generally, any time where you want to define the same recipe for lots of different targets but you don't want to have to write them all out one at a time. Your assertion that this construct is not common is

[bug #54854] multi-target rules invoked too often with -j2

Follow-up Comment #3, bug #54854 (group make): If by "a warning (or a note)" you mean something printed by GNU Make, instead of content in the documentation (this is already described there) then no, we can't do that, because this behavior has many uses, and is used in many situations and in many

[bug #65383] copy command does not work on Windows

Update of bug #65383 (group make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: I'm not sure what is

[bug #65438] Sort print-targets output.

Follow-up Comment #2, bug #65438 (group make): I think the term "sort" isn't really correct here: from the user's point of view they simply see the output in a different, and deterministic, but still more or less random, order than they did before. I doubt most users will be able to map the

[bug #65273] Potential bug in the info function?

Follow-up Comment #9, bug #65273 (group make): Note that the trick in John's book no longer works without warnings in the current Git-based code: $ ./make Makefile:3: warning: invalid variable name ' ' Makefile:4: warning: invalid variable reference ' ' Makefile:4: [ ] make: *** No targets.

[bug #65510] INSTALL file not present

Update of bug #65510 (group make): Status:None => Works for me Open/Closed:Open => Closed ___ Follow-up Comment #1: The INSTALL file is not

[bug #41781] Provide a fast fail path when a target is compromized during a parallel build

Follow-up Comment #4, bug #41781 (group make): Definitely I don't anticipate making any change in error handling the default. The idea I had 10yrs ago is still my best idea (perhaps with an option to allow "immediate kill" as suggested by Patatti) but it's gotten even more complex since then:

[bug #65383] copy command does not work on Windows

Update of bug#65383 (group make): Item Group: Bug => Enhancement ___ Follow-up Comment #1: I'm sorry but I don't understand what you mean by "include it into make". In what way would it be

[bug #65360] Extend -p output with export status of each variable.

Follow-up Comment #3, bug#65360 (group make): Man I'm batting .000 today when it comes to Savannah markup :-/ ___ Reply to this item at: ___ Message

[bug #65360] Extend -p output with export status of each variable.

Follow-up Comment #2, bug#65360 (group make): I'm not a fan of adding the "do not export" to comments for non-exported variables. Non-exporting is the default and so we should just not say anything for non-exported variables. As for export, would it be better to use the make syntax for this,

[bug #65359] submake might will lose variable values if their names contain special char

Update of bug#65359 (group make): Item Group: Bug => Documentation ___ Follow-up Comment #7: The manual says: +quote+ When using export by itself or .EXPORT_ALL_VARIABLES to export variables by

[bug #63840] make allows match-anything rules to match files with the default suffixes

Follow-up Comment #4, bug#63840 (group make): Sorry for the delay in examining this bug. I understand what you are saying. A counter-argument would be that if you wanted to use "-r" and also provide match-anything rules, that you should also be assigning proper suffixes via ".SUFFIXES" to

[bug #65273] Potential bug in the info function?

Follow-up Comment #6, bug#65273 (group make): I mean, there IS a reasonable way to get the same effect; I showed one possibility in my response. Yes, it looks slightly different but the result is the same and there are no warnings. Alternatively the Emacs makefiles could disable these new

[bug #65276] SECONDEXPANSION doesn't work correctly with escaped spaces

Follow-up Comment #1, bug#65276 (group make): I will take a look at this, but up-front I will say that GNU Make, like all POSIX make instances, does not intend to support pathnames containing spaces as either targets or prerequisites. It may be possible to get them to work in some limited

[bug #65273] Potential bug in the info function?

Update of bug#65273 (group make): Component Version: 4.4.1 => SCM ___ Follow-up Comment #3: It's usually a good idea to check the NEWS file for things that might cause differences in behavior;

[bug #63362] make 4.4: different behavior with -j1 and -j2 when building manpages from git

Update of bug#63362 (group make): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #9: I haven't seen a

[bug #63852] Two test failure running the test suite as root

Update of bug#63852 (group make): Item Group:None => Build/Install ___ Reply to this item at: ___ Message

[bug #64822] Fix appending to a pattern specific variable.

Follow-up Comment #7, bug#64822 (group make): I pushed the changes here with some small fixups. These changes are good as far as they go but I think there are still some remaining issues to be addressed. I will raise this on the mailing list before closing this issue.

[bug #36486] Overrides and append to pattern specific variables

Update of bug#36486 (group make): Status:None => Duplicate Open/Closed:Open => Closed Triage Status:None => Major Effort

[bug #64803] Fix origin of variables from env when -e is set.

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

[bug #65211] Fix load and loadapi tests.

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

[bug #65172] Fix a buffer overrun on a variable with a long name.

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

[bug #65211] Fix load and loadapi tests.

Follow-up Comment #2, bug#65211 (group make): Thanks Dmitry! ___ Reply to this item at: ___ Message sent via Savannah https://savannah.gnu.org/

[bug #64571] Add option to print targets

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

[bug #64571] Add option to print targets

Follow-up Comment #15, bug#64571 (group make): Just to point out, GNU Make doesn't provide any support for autocompletion in its package. Any autocompletion that is available is provided by other packages, for example the bash-completion package: $ head -n1

[bug #64571] Add option to print targets

Follow-up Comment #13, bug#64571 (group make): It depends on what you mean by "this context". If what we are suggesting is to use this new JSON output format so that we don't need to create an option to print targets, then it's very relevant since the goal of this option is to provide input for

[bug #64571] Add option to print targets

Follow-up Comment #11, bug#64571 (group make): Tim Murphy had a proposal and even a patch to generate JSON, posted to bug-make a few weeks ago: https://lists.gnu.org/archive/html/bug-make/2023-12/msg00027.html Overall I like JSON but I'm not convinced it will be as helpful for this situation.

[bug #64571] Add option to print targets

Follow-up Comment #8, bug#64571 (group make): Let me just say up-front that my biggest concern with this is going in the direction you suggest: > I guess you can always add flags to refine the behaviour later if necessary Just... no. I won't introduce an entire family of options that tweak and

[bug #65019] Let function segfaults when foreach return empty list

Update of bug#65019 (group make): Status:None => Fixed Open/Closed:Open => Closed Operating System:None => Any Fixed Release:

[bug #65006] Implement second expansion of .EXTRA_PREREQS.

Update of bug#65006 (group make): Status:None => Fixed Open/Closed:Open => Closed Component Version: SCM => 4.3 Fixed Release:

[bug #64428] Document how to simplify debug output.

Update of bug#64428 (group make): Status:None => Duplicate Open/Closed:Open => Closed Operating System:None => Any Triage Status:

[bug #64402] error parsing functions in braces inside ifeq, ifneq

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

[bug #64339] $(filter) and $(filter-out) interpret "match" in surprising ways

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

[bug #64571] Add option to print targets

Follow-up Comment #6, bug#64571 (group make): I have asked below, and I'm still waiting for an answer. Until there's some agreement on the answer, I don't see how we can move forward no matter how many "hacky solutions" exist in the wild. In fact, the more "hacky solutions" there are the LESS

[bug #64543] Fix "make -j" for Docker container

Update of bug#64543 (group make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: Thanks for the update.

[bug #64551] Possible null pointer dereference on the function get_buffer

Update of bug#64551 (group make): Status:None => Duplicate Assigned to:None => psmith Open/Closed:Open => Closed

[bug #64964] GNU Make deletes intermediate targets that are pattern-rule dependancies

Update of bug #64964 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: As Dmitry says this

[bug #64650] LD is not reported as an IMPLICIT VARIABLE

Update of bug #64650 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: There isn't any such

[bug #64664] what could cause make to stop with "make[3]: *** wait: No such file or directory. Stop."

Update of bug #64664 (project make): Open/Closed:Open => Closed ___ Follow-up Comment #2: I think that this should be brought up and discussed on the bug-make@gnu.org mailing list rather

[bug #64818] patsubst shorthand documentation bug?

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

[bug #64924] Missing Close Parenthesis

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

[bug #64886] order-only prerequisite on a .PHONY line makes prerequisite "unmakeable"

Update of bug #64886 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: Agreed: in fact this

[bug #64571] Add option to print targets

Follow-up Comment #3, bug #64571 (project make): This is the right place for patches. I did look at this patch; it's not quite right (IIRC) but of course it could be adjusted relatively straightforwardly. The hard thing about this request is not the code. The hard thing is the design. I'm

[bug #64818] patsubst shorthand documentation bug?

Follow-up Comment #5, bug #64818 (project make): Andreas also missed a % :) $(patsubst %World,%Earth,$(STR)) ___ Reply to this item at: ___ Message

[bug #63439] [Regression] --no-builtin-variables with --warn-undefined-variables trigger warning on GNUMAKEFLAGS

Follow-up Comment #12, bug #63439 (project make): Yes, my example didn't use the -R option (--no-builtin-variables). That's why I didn't see the problem. As noted by Pekka S, this is already fixed in Git and the fix will be available in the next release of GNU Make.

[bug #63439] [Regression] --no-builtin-variables with --warn-undefined-variables trigger warning on GNUMAKEFLAGS

Follow-up Comment #9, bug #63439 (project make): Please be sure to post the output of *make --version* so we know what version of GNU Make you are using. Also please show a minimally reproducible example: I looked at the Makefile in the directory on GitHub you pointed to and there is no

[bug #64746] Exponential Runtime in make 4.4.1 when export is used

Follow-up Comment #3, bug #64746 (project make): Many have asked for a new "optional simple assignment" variant. I'm not opposed to it. Another option that will work with most currently available versions of GNU make, although it looks somewhat scary, is described here:

[bug #64472] $(CP) is an empty string

Update of bug #64472 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #3: I think there's some

[bug #64339] $(filter) and $(filter-out) interpret "match" in surprising ways

Follow-up Comment #1, bug #64339 (project make): I believe that the use of PATTERN here is intended to make you understand that it's the same matching rules as with pattern rules or other uses of patterns, such as the patsubst function; patterns that don't contain a "%" always require the entire

[bug #64288] The flag --no-print-directory becomes effective too early

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

[bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

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

[bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

Follow-up Comment #9, bug #64185 (project make): I agree that this is simply a bug. There are definitely places where it's impossible to "do the right thing" with relation to GNU Make's conditionals, because there is no easy way to tell them apart from non-conditional statements (this is the

[bug #40942] Load directive breaks Makefiles

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

[bug #63219] Introduce a close function for loadable plugins.

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

[bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

Update of bug #64185 (project make): Item Group: Bug => Enhancement ___ Follow-up Comment #3: I agree that due to parsing limitations it's very difficult to manage this as make's keywords are

[bug #64129] Using $(filter ...) on a variable with a large number of words causes seg fault

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

[bug #63868] Document MAKEFLAGS pitfalls.

Update of bug #63868 (project make): Summary: Document MAKEFLASG pitfalls. => Document MAKEFLAGS pitfalls. ___ Reply to this item at:

[bug #64016] Simplify update_goal_chain.

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

[bug #64107] -R and -r settings in MAKEFLAGS are delayed until build time

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

[bug #64115] make warns about undefined variable GNUMAKEFLAGS

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

[bug #64124] Use after free in expand_variable_buf.

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

[bug #64107] -R and -r settings in MAKEFLAGS are delayed until build time

Follow-up Comment #2, bug #64107 (project make): This is a good change, thanks! ___ Reply to this item at: ___ Message sent via Savannah

[bug #64016] Simplify update_goal_chain.

Follow-up Comment #2, bug #64016 (project make): I installed the code cleanup, thanks. I don't understand the test that was added though. How does this test show that both rules are run at the same time? It seems like it would behave the same even if they were not. Don't you mean something

[bug #64112] ...\$(...) or ...\\$(...) give unexpected result

Update of bug #64112 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: I'm not sure which

[bug #63686] implement a flag to promote make warnings to fatal errors

Update of bug #63686 (project make): Status:None => Fixed Open/Closed:Open => Closed Operating System:None => Any Triage Status:

[bug #63990] Fix a buffer overflow in warning.c.

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

[bug #63856] .WAIT does not work as special target on command line.

Update of bug #63856 (project make): Status:None => Fixed Open/Closed:Open => Closed Operating System:None => Any Fixed Release:

[bug #63981] suppress "-jN forced in submake" warning with -j1

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

[bug #63981] suppress "-jN forced in submake" warning with -j1

Follow-up Comment #1, bug #63981 (project make): I made this change because of the manual although I'm not exactly sure it's the best idea. Note that there are better ways to force a makefile to be not parallel; for example you can use: all: $(MAKE) --eval '.NOTPARALLEL:' -f one.mk

[bug #63867] Port to older versions of gnu tar.

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

[bug #63984] Error 2133

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

[bug #63867] Port to older versions of gnu tar.

Follow-up Comment #3, bug #63867 (project make): Of course when I say "every invocation of tar by GNU make" I obviously mean, in the GNU make source directory only. ___ Reply to this item at:

[bug #63867] Port to older versions of gnu tar.

Follow-up Comment #2, bug #63867 (project make): I think the recent email is because the tar options are also used to generate the release tarball, not just to generate the tarball containing error results. Note that we manage these options simply by exporting the TAR_OPTIONS variable, which

[bug #63856] .WAIT does not work as special target on command line.

Update of bug #63856 (project make): Component Version: 4.4.1 => 4.4 Summary: The special target .WAIT does not work as special target on command line. => .WAIT does not work as special target on command line.

[bug #63852] Two test failure running the test suite as root

Follow-up Comment #1, bug #63852 (project make): Well, we would have to use a separate check: whether we can write to directories that don't have write privileges. It could be done. ___ Reply to this item at:

  1   2   3   4   5   6   7   8   9   10   >