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

[Paul D. Smith]

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 +

(decode_switches): If non-option arg is "-", ignore it.

So, I'm not sure why this was done or what the right thing to do is going
forward.  Maybe we should be printing a warning.  I wonder if it's there
because some makefiles contain recipes like this:

  submake:
  $(MAKE) -$(MAKEFLAGS)

where, if MAKEFLAGS is empty you get *make -*.

I will think about it.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 work correctly.  I do agree that this behavior is
duplicative and unpleasant.

For example:

$ make x
make: *** No rule to make target 'x'.  Stop.

but:

$ make -
make: *** No targets specified and no makefile found.  Stop.




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 use.

It seems to me that we have two different behaviors: for global .EXTRA_PREREQS
I just can't imagine anyone ever wanting to enable this warning.  Can someone
show an example of a situation where it would be useful for global
.EXTRA_PREREQS?

But for target-specific .EXTRA_PREREQS I can see how it could be useful.

So maybe what we want to do instead of (or in addition to) creating the
warning is to say that the entire behavior of omitting extra prereqs as a
prerequisite to itself only applies to global .EXTRA_PREREQS; that is in the
manual instead of:

> Note @code{make} is smart enough not to add a prerequisite listed in
@code{.EXTRA_PREREQS} as a prerequisite to itself.

we make it explicit (and in the code) that this only applies to global
.EXTRA_PREREQS; something like:

> Note @code{make} is smart enough not to add a prerequisite listed in a
global setting of @code{.EXTRA_PREREQS} as a prerequisite to itself.

Then we can keep all the default behaviors, including warning about circular
dependencies using the already existing warning option for this that you
proposed in the other bug, because by definition those warnings won't apply to
global .EXTRA_PREREQS due to the special case above, but they will still apply
to target-specific .EXTRA_PREREQS.

Thoughts?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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* you can't use *make
-f* because "-f" is a valid option name.  You'd have to use *make -- -f*.

However, I do agree that *make -* (one dash) should be considered an error. 
Many programs use a single dash to mean "read from stdin" but make doesn't do
this.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 it.

I suppose the difference we're tracking is whether the option is passed via
the environment or via the command line?

I wonder if we should simply keep the same behavior for both; if we see a
jobserver-auth on the command line we also ignore -j.  This would still allow
people to run an explicit $(MAKE) -jN and have it do the right thing.

But that might be tricky since we'd have to understand whether the
jobserver-auth was actually on the command line or whether it came from the
environment earlier.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #65323 (group make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
Operating System:None => POSIX-Based
   Fixed Release:None => SCM

___

Follow-up Comment #2:

Pushed; thanks Dmitry!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65324] Fix crash in disable_builtins.

[Paul D. Smith]

Update of bug #65324 (group make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
Operating System:None => Any
   Fixed Release:None => SCM

___

Follow-up Comment #2:

Pushed, thank Dmitry!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #65536 (group make):

  Item Group: Bug => Documentation  
  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Medium Effort  

___

Follow-up Comment #3:

I rewrote this entire chapter (or at least most of it).  It passes builds on
my system.  Please let me know if it still fails with older texinfo / makeinfo
environments.  I will have to figure out how to run with older versions if so.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #65537 (group make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #9:

I pushed a change to switch GNU Make to the latest stable gnulib branch.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #65273 (group make):

  Status:None => Wont Fix   
 Open/Closed:Open => Closed 

___

Follow-up Comment #10:

I have decided, for now, to keep the new behavior.  I'm open to continued
discussion.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #65600 (group make):

  Status:None => Wont Fix   
 Open/Closed:Open => Closed 

___

Follow-up Comment #10:

Thanks for the comment; I will close this because I don't think we should
change this long-standing behavior of --silent.

You might consider checking this blog post; it describes a "common" way to
utilize silent / verbose rules.  I haven't checked the details of the Linux
man pages build system to know how much overlap etc. there is (or isn't):

https://make.mad-scientist.net/managing-recipe-echoing/


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #65596 (group make):

  Status:None => Wont Fix   
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

As Dmitry mentions most functions don't have an entry in FEATURES.  They can
almost always be detected by simply trying to invoke them and observing they
don't work.

I will say that this is becoming more difficult now that we are providing
warnings about invalid variable names (containing spaces).  We may need to
reconsider this position for future new functions, or maybe just provide a way
to get a list of defined function names.

Another option is to check for some other feature that was added in the same
release, such as 'jobserver-fifo'.  Not great I know.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 98a709a5..871bdb09 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -19,7 +19,7 @@
 checkout_only_file=README.git

 # Choose a specific version of gnulib, when checking out
-GNULIB_REVISION=stable-202307
+GNULIB_REVISION=stable-202401

 # Always copy files rather than symlink
 copy=true




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 . -name '*.F'))

(this is just one example there are 300+ spread across the makefiles).

At the same time I see that various makefiles are forcing all variable
assignments to be exported; for example:

src/peigs/src/c/Makefile.proto:.EXPORT_ALL_VARIABLES:


There are also instances of .EXPORT_ALL_VARIABLES in some Makefiles, but these
are probably not a problem because the Makefiles appear to be for BSD make
(GNUmakefile is used for GNU Make).  So, there appear to be about 5 makefiles
that have this setting.

But, when the Makefile.proto above is included in another makefile, that sets
that parameter for every make instance that includes it.

The simplest solution here is to go through and remove all those
.EXPORT_ALL_VARIABLES: settings.  This is just a very bad idea.  If there are
specific variables that need to be exported then those, and only those, should
be exported.

Unfortunately there is not any simple solution right now, except either fix
the makefiles or else limit your version of GNU Make to 4.3 or earlier before
this change was made.

I have been thinking about how to mitigate this issue and I just don't have
any good ideas.  There doesn't seem to be any good heuristic we can use to
avoid the behavior without also introducing bizarre and unexplainable edge
cases.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 $(shell ...) functions, with recursive variable
assignment; e.g. things like:

  FOO = $(shell some script here)

along with either forcing all variables to be exported:

  .EXPORT_ALL_VARIABLES:

or, just exporting directly a lot of variables that contain shell commands,
like:

  export FOO = $(shell some script here)


This has always been very inefficient because this shell script is invoked
every time the variable is expanded, instead of only once when the variable is
assigned.

But, starting in GNU Make 4.4 this potentially became much more inefficient
due to this change:
https://git.savannah.gnu.org/cgit/make.git/tree/NEWS?h=4.4#n73

To fix this, you should ensure that your makefiles adhere to at least one of
these rules:
* Always use simple assignment (FOO := $(shell ...)) when using the $(shell
...) function unless there's a reason that this can't work.
* Avoid setting .EXPORT_ALL_VARIABLES: special target and instead explicitly
export only the variables you need.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #65448 (group make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
Operating System:None => Any
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #2:

Fix applied; thanks Jouke


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #64085 (group make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Medium Effort  

___

Follow-up Comment #1:

Fixed, thanks for the note.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #65359 (group make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #8:

Added some notes about this, thanks for the note.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #65268 (group make):

  Item Group:None => Bug
  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Component Version:None => 4.0
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #1:

Fixed, thanks for the report.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65438] Sort print-targets output.

[Paul D. Smith]

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) as the sorting function?

For justification I don't know that we really need one; if it's useful to us
to sort, we should sort even if users won't find it useful.  Someone looking
at the output by hand may find it useful although it seems just as likely they
will run the output through sort themselves if they want it sorted.

It's too bad we don't have a simple way to sort the output in the test
framework.  It will be annoying if we choose "good" filenames and the test
passes, but then we switch our hashing around and it breaks again.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 must support versions of GNU Make prior to 4.3 (released in 2020) then
you will have to use alternate methods.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 just not true: this
appears all over the place in all sorts of makefiles.  In fact I just checked
a makefile generated by GNU's automake tool, and it uses the construct. 
Here's one simple example of an obvious way this might be used:

SUBDIRS := $(wildcard */.)

all: $(SUBDIRS)

$(SUBDIRS):
$(MAKE) -C $@

.PHONY: all $(SUBDIRS)


There's no reason this should give any sort of warning, even when used with
-j.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 thousands of makefiles.  Generating messages would not
be appropriate.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 being requested and no followup.  If a followup is
provided this can be reopened.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65438] Sort print-targets output.

[Paul D. Smith]

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 output they see onto the input make reads except in simple
situations.  When you start having lots of include files etc. it becomes hard
to follow.

Question: why not just _actually_ sort the output so the results are ordered
by pathname of the target instead of by order discovered?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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.  Stop.




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65510] INSTALL file not present

[Paul D. Smith]

Update of bug #65510 (group make):

  Status:None => Works for me   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

The INSTALL file is not checked into the Git repository.  It's added as part
of the build process and appears in the downloadable source tarballs.

I've checked both the version you specified (4.4) and the latest (4.4.1) and
both have INSTALL files.

https://ftp.gnu.org/gnu/make/make-4.4.tar.gz
https://ftp.gnu.org/gnu/make/make-4.4.1.tar.gz


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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: that solution works well for POSIX systems which use a
pipe to manage the jobserver, but on other systems like Windows we simply use
a counting semaphore so there's no facility there to notify the other
instances of make by using different tokens in the jobserver pipe.

We'd need to create some separate, different communication channel for those
systems.

This has been hiding behind work I've been trying to do to clean up the way
make dies, which is currently not reliable because it calls a complex,
non-signal-safe method in a signal handler.  Unfortunately changing THAT
requires reworking how we handle signals in general, most specifically as
relates to the jobserver facility.  Sigh.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 included?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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, like:

+verbose+
# makefile (from 'Makefile', line 1)
export FOO = bar
-verbose-

?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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
default, only variables whose names consist solely of alphanumerics and
underscores will be exported. To export other variables you must specifically
mention them in an export directive.
-quote-

I suppose we can add an extra admonishment saying that some shells will strip
out environment variables with "special" names and so the only portable way to
provide environment variables is with standard names.

There's nothing make itself can do about this obviously.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 ensure that your source files are handled properly:

hello.c:
%: %.o; $(info $@ from $<)

# this should be added since you have a match-anything rule
.SUFFIXES: .c


However, I tend to agree with you that this is perhaps too much "inside
baseball" for the default behavior.
I think you are mostly correct in your determination of the problem with one
exception: when the .SUFFIXES list is cleared explicitly, then we should not
create any dummy pattern rules and thus these match-anything rules SHOULD be
matched.

What we should probably do is not clear the .SUFFIXES list by default when -r
is given, but instead simply not create the default rules associated with
those suffixes.

I have a simple patch that does that; if you agree that's OK I'll push it
along with your tests.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 warnings, if they are deemed more annoying than
helpful.

The problem is that at least 70% of the questions I've been answering on
StackOverflow in the last 5 years more or less boil down to misunderstanding
how make handles expansion, and a lot of those misunderstandings could be
helped if make complained about invalid variable names; for example:

all:
echo $(git rev-parse HEAD)

will now show a warning (which can be either disabled or converted into an
error via options) because "git rev-parse HEAD" is not a valid variable name.

Leaving these checks disabled by default is not a good solution since the very
people who need this help most, will not benefit from them.

Of course we COULD add "special case" facilities for various projects' special
tricks but I'm not a fan of this approach.  And for this specific case, we
would be disabling warnings for situations like:

all:
echo $ (CURDIR)

which admittedly is probably rare but still seems like it is a bizarre special
case to keep.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 situations with a lot
of effort, but it's not a goal of GNU Make to allow this to work.  We don't
have any tests of this behavior in our regression tests for example.

If it ends up being simple to make this work then we will try to do so, but if
it's not easy or straightforward then we will not try to do it.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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; in this case see:

https://git.savannah.gnu.org/cgit/make.git/tree/NEWS#n68

I understand what the Emacs makefile is trying to do: by adding this invalid
variable reference, which used to be silently ignored, they are adding
indentation.  For example this:

$(info  foo)

shows the string:

foo

because leading whitespace is ignored for all functions and arguments in GNU
Make.

But this:

$(info $ foo)

shows the string:

foo

since the invalid variable "$ " ends the leading whitespace and expands to
nothing.

Unfortunately I can't think of a good way to continue to allow this to work,
other than simply disabling the warning by default which I'd really prefer to
not do.

The problem is that (a) there is no way to create a variable name containing,
or consisting of, whitespace, and (b) modifying the warning check to allow a
variable of just a single space without comment seems to me to be allowing an
extremely common potential error to be silently accepted.

I wonder how common this particular little trick is, out in the world.  Of
course it could easily be changed to do something like:

. :=
$(info $.  foo)

but it does involve a change.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug#63362 (group make):

  Status:None => Wont Fix   
 Open/Closed:Open => Closed 

___

Follow-up Comment #9:

I haven't seen a groundswell of other makefiles with similar issues and the
issue with the Git makefiles has been addressed, so I won't try to do
something about this.  Please add a comment if you disagree and we can
discuss.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug#63852 (group make):

  Item Group:None => Build/Install  


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug#36486 (group make):

  Status:None => Duplicate  
 Open/Closed:Open => Closed 
   Triage Status:None => Major Effort   

___

Follow-up Comment #3:

This was addressed as part of bug #64822


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug#64803 (group make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Medium Effort  

___

Follow-up Comment #2:

I applied these changes, with some differences in implementation, plus all the
tests provided here except the changes to the MAKEFLAGS tests which are no
longer needed.

Thanks Dmitry!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65211] Fix load and loadapi tests.

[Paul D. Smith]

Update of bug#65211 (group make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #3:

Applied and pushed.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug#65172 (group make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #2:

I applied the fix discussed on the mailing list, plus the test below.  Thanks
for the test as always!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65211] Fix load and loadapi tests.

[Paul D. Smith]

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

[Paul D. Smith]

Update of bug#64571 (group make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
Operating System:None => Any
   Fixed Release:None => SCM
   Triage Status:None => Medium Effort  

___

Follow-up Comment #17:

I pushed an implementation to Git.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64571] Add option to print targets

[Paul D. Smith]

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 /usr/share/bash-completion/completions/make
# bash completion for GNU make -*- shell-script
-*-

$ dpkg -S /usr/share/bash-completion/completions/make
bash-completion: /usr/share/bash-completion/completions/make


As far as I'm aware this package is part of the standard system installation
on many/most GNU/Linux distributions.

So it's not a matter of someone installing make vs. jq.  It's a matter of
whether the maintainers of these generic packages are willing to write
completion scripts which require other non-standard packages to be installed
before they can be of use, or whether they will simply continue to use their
current workarounds because they don't want to make that requirement.

If the latter then this request has failed its intended audience, I expect.

Also getting jq for Windows etc. is less simple, although I don't know if
those platforms have any use for it anyway.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64571] Add option to print targets

[Paul D. Smith]

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 tools that want to list the possible goal targets (for
command line completion or IDEs).

I think that the way it will have to work is that we don't try to rebuild
makefiles when listing targets.  I don't see any feasible alternative given
the use-case referred to here.  This means that the list of targets may be
incomplete in some situations but it should be rare that a target you'd really
want to add to the command line would not be listed, except in the most
extreme cases.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64571] Add option to print targets

[Paul D. Smith]

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.

The problem with JSON is that (a) it requires special tools to parse it, you
can't do it with traditional POSIX tools like sed or sh, (b) these tools (like
jq for example) are not part of most standard systems and so can't be relied
on to exist everywhere, and (c) jq, at least, is somewhat tricky to use
correctly especially if you want to do matching etc.

The last point is not that bad since someone who is proficient with jq will
presumably create some bash completion script one time then everyone will use
it, but the first two are problematic: it would not be popular to force
systems to install jq if they wanted GNU Make command completion for example.

Regarding how -p manages remaking makefiles, this is not an issue because -p
already doesn't inhibit builds (that is when you add -p make will still do all
its normal builds).  That's why people often use -np (the -n inhibits normal
builds).  So if you ask what -n does regarding remaking makefiles, it will
normally rebuild them; the -n option doesn't prevent ALL commands from
running: it will for example run any command that is prefixed with "+" or
contains the string "$(MAKE)" (or "${MAKE}") so that even when you run with -n
you still invoke sub-makes to see what they would have built.

So, unfortunately I don't think we can look to either -p or -n for help in
deciding how to handle this situation.

Regarding a putative --format option, I don't think it needs to do every
single thing immediately but it should at least be clear how it might be
extended to support new facilities in the future.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64571] Add option to print targets

[Paul D. Smith]

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
customize this output in various ways.

If someone feels the need for this level of customization then I think the
only way forward is to introduce a kind of "format syntax" that will allow
users to provide customized output (a well-known example of this is Git's "git
log --format" option but there are many examples that predate it).  Ideally
this syntax would be sufficient to generate, for example, the current print
database output (a default syntax), and allow users to change it.  This would
be quite a bit of work and I don't plan to work on it, but if someone else
wants to please provide a proposal on bug-make@gnu.org and we can discuss the
details.

Given the parameters laid out (used to generate targets for command-line
completion) it seems like:
* We definitely want to print targets with no recipe (all: often, for
example)
* We definitely want to print phony targets
* We don't want to perform recursion into sub-makes, or any other "normal"
recipes

In addition it seems like we would also want the following:
* Don't show builtin targets (these are basically suffix rules)
* Don't show special targets like .PHONY, .SILENT, .PRECIOUS, etc.

The big open question is what to do about remaking makefiles (
https://www.gnu.org/software/make/manual/html_node/Remaking-Makefiles.html ). 
If we do not do this then in some situations some targets which you _could_
build, will not show up in the list (because they are defined in a makefile
that will be remade but was not).  But if we DO do this then the output
generated by make will first be any output created when remaking makefiles,
followed by the list of targets, which would mess up any utility trying to
parse the output.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug#65019 (group make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
Operating System:None => Any
   Fixed Release:None => SCM

___

Follow-up Comment #3:

Applied, thanks Jouke.

FYI please remember to include a reference to the bug# in the Git commit
message.  Unfortunately I forgot to add it by hand when I applied your patch.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug#65006 (group make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Component Version: SCM => 4.3
   Fixed Release:None => SCM

___

Follow-up Comment #3:

Applied; thanks Dmitry!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug#64428 (group make):

  Status:None => Duplicate  
 Open/Closed:Open => Closed 
Operating System:None => Any
   Triage Status:None => Medium Effort  

___

Follow-up Comment #3:

Dmitry I wrote a new appendix that provides various debugging etc. methods. 
Please review that and we can discuss issues on the bug-make@gnu.org mailing
list if there are specific things from your suggestions here that I missed.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug#64402 (group make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #1:

I fixed this.  Also commas used as variable names now work correctly.

As a side-effect, only parens or braces which are part of a variable reference
are counted, so if you had something like this:


ifeq ((foo,bar),)


that is now a syntax error (of course it's find if you have a variable
reference that _expands_ to (foo,bar)).


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug#64339 (group make):

  Item Group:None => Documentation  
  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #2:

I updated the documentation, thanks Eli.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64571] Add option to print targets

[Paul D. Smith]

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 likely it is that any
specific facility we implement inside GNU Make, will be correct for all or
even most of the uses people have.

What exactly should this new option do?  It's easy enough to say "print the
targets" but that is TOO simplistic.

I assume users only care about explicit targets, not implicit targets
(patterns etc.)  Are people hoping to see all possible targets that the
makefile could build, even intermediate targets?  That pretty much can't be
done.

Do people want to see phony targets?  Only targets that have recipes, or all
prerequisites as well (a prerequisite is also considered a target by make of
course)?

I suppose we can just do whatever is simple and if people aren't happy with
the results they can revert to whatever they were doing before.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug#64543 (group make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

Thanks for the update.  Closing.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug#64551 (group make):

  Status:None => Duplicate  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

I don't see how the "second" xrealloc() would return 0; the entire point of
xrealloc is that it never returns 0.

However, I can see where the behavior of the code might lead to an infinite
loop.

This issue was already addressed in GNU Make 4.3 via bug #13651
The version you're testing (4.2) was released in 2016.

It's certainly helpful to check for errors in tools like GNU Make but please
check either the most recent published version or, even better, the current
Git HEAD version.

Thanks!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #64964 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

As Dmitry says this is not a bug.

You are confusing "built-in rules" and "implicit rules".

Built-in rules are built into make and will be present regardless of whether a
makefile is parsed are not, unless you remove them with the -r option.

Implicit rules are suffix rules or pattern rules.

Explicit rules are rules that specify an explicit target (are not implicit
rules).

Built-in rules are always implicit (since it doesn't really make sense to have
explicit built-in targets).

But, implicit rules don't have to be built in: any suffix or pattern rule,
even ones that are defined in a makefile, are still implicit.

You don't have to use .SECONDARY etc.  All you have to do is mention the
targets you want to be preserved as a target or prerequisite SOMEWHERE in the
makefile.  So in your example, all you have to do is define some target that
lists these files you don't want to be deleted as a prerequisite.

The reason that make re-runs the sh all the time is that your pattern rule is
not creating its target.  That is, if your makefile was like this:


foo%: foo%.txt
cat $<
touch $@
foo%.txt: foo%.sh
sh $< > $@


then make would know, because *foo1* exists and is newer than *foo1.sh*, that
*foo1.txt* did not need to be rebuilt.

If you don't want to do that you could create a rule like:

all-txts : foo1.txt foo2.txt foo3.txt ... fooN.txt

and that would be enough to avoid these targets being deleted as intermediate
targets.

If you want to discuss this further I recommend sending an email to the
help-m...@gnu.org mailing list.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #64650 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

There isn't any such thing as an "implicit variable" in GNU Make.  The name of
the documentation section you refer to is _Variables Used by Implicit Rules_

Although LD is set with a default value of "ld", the LD variable not used in
any implicit rule defined by GNU Make, so it doesn't work in that section.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 than here in the bug tracker.

In order to help we'd need to know some information from the config.h
generated on the system (for example, whether HAVE_WAITPID is set).  You'll
need to investigate whether your version of waitpid(2) accepts the -1
argument, as defined by POSIX, etc.

Debugging this type of thing via the bug tracker just isn't efficient.  If we
figure out the problem and there's something for GNU Make to do, we can add
info here and re-open this issue.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64818] patsubst shorthand documentation bug?

[Paul D. Smith]

Update of bug #64818 (project make):

  Item Group: Bug => Documentation  
  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
Operating System:None => Any
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #6:

I've resolved this by simply removing that redundant info from the discussion
of the patsubst function.  The reference to the section on Substitution
References remains and the description in that section is clearer as to how
this works.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64924] Missing Close Parenthesis

[Paul D. Smith]

Update of bug #64924 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #1:

Fixed; thanks for the note.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #64886 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

Agreed: in fact this is a primary reason to choose PHONY targets over
something like FORCE rules; they improve performance by avoiding that search
(as well as being a bit cleaner in syntax).

Greg are you saying that if you do NOT use the order-only separator you get
different behavior?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64571] Add option to print targets

[Paul D. Smith]

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 just not really that convinced that the simplest thing is going
to be useful to people.

GNU Make is used by so many people for so many things, and I'm leery of
creating some new facility that ends up being "not really right" for what
people want to do, but that then must be maintained forever going forward.

First of all, of course there's no way to show any target that is created by
an implicit rule (well this could be possible but would be a lot of work; we'd
have to have a mode where we resolve all targets without actually building
anything).

Second, it will show explicit targets... but ALL of them, even internal ones
etc.  Even in the comments below someone suggested "especially for phony
targets"... well, now are we suggesting that we want not just one option but
some kind of suite of options that can choose different types of target output
based on various criteria?  It just feels unpleasant.

Here's an experiment you can run in your makefile environment:


$ make -pn | sed -n 's/^\([^#][^=]*:\).*/\1/p;'


What do you get out of this?  This is "more or less" what a simple
implementation of "show all explicit targets" would generate (you can ignore
the suffix rules sprinkled through the output).

Is that really what people are looking for?  I'm just skeptical that this
wouldn't degenerate into a morass of conflicting requests for new features.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64818] patsubst shorthand documentation bug?

[Paul D. Smith]

Follow-up Comment #5, bug #64818 (project make):

Andreas also missed a % :)

$(patsubst %World,%Earth,$(STR))




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 reference to
GNUMAKEFLAGS or the "help" target there and I didn't have the energy to go
searching through the entire project looking for it.

Here is the behavior I see with GNU Make 4.4.1:


$ unset GNUMAKEFLAGS

$ make --version
GNU Make 4.4.1
Built for x86_64-pc-linux-gnu
  ...

$ echo '$(info GNUMAKEFLAGS = $(GNUMAKEFLAGS))' | make -f-
--warn-undefined-variables
GNUMAKEFLAGS = 
make: *** No targets.  Stop.


showing no warnings.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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:

https://make.mad-scientist.net/deferred-simple-variable-expansion/

I haven't actually tested it to make sure it fixes this specific problem but
based on my understanding of the issue it should.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #64472 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

I think there's some confusion.  The section you are reading is simply
describing some tips for writing portable makefiles.  If you use those
utilities your makefiles are more likely than not to be portable across
POSIX-based systems.

That section doesn't mean to say that every one of those utilities also has an
associated variable defined as a built-variable in make.

The variables specifically listed on that page exist.  No other utility on
that page has a variable associated with it.

I agree that the text "Additional utilities that can be used via Make
variables are" is misleading but this just means that you could use these
utilities via make variables (if you created the make variables).  It's not
intending to say that these variables already exist.

To me this entire section is not really useful anymore, or at least large
parts of it are not useful: POSIX systems are far more compatible, and lots of
people use GNU Make on non-POSIX systems (like Windows) which aren't
well-served by this section.

You can run "make -pf/dev/null" to see all the built-in rules and variables in
your instance of GNU Make.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 word to match identically, everywhere in GNU Make.

However it's not an excuse: definitely the docs could be more clear here.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #64288 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

This behavior is intentional: setting MAKEFLAGS as a make variable assignment
modifies the behavior of the currently-running make.  If users want to disable
printing directories for the current makefile they can do so by setting the
MAKEFLAGS variable.

If you don't want to disable this setting for this instance of make, don't add
it to MAKEFLAGS.

If you want to leave print-directories for this makefile but have it unset for
children of this makefile, then you can add the flag to the invocation of the
child makes.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #64185 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
Operating System:None => Any
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #10:

Fixed but I put the wrong bug number in the commit *sigh*


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 difference between GNU Make's conditionals and the C
preprocessor's conditionals, which use an invalid syntax).

However, this example plainly contravenes the explicit text of the
documentation AND I don't see any reason for it to do so, so I think it's a
bug.  It seems simple to fix as well:

diff --git a/src/read.c b/src/read.c
index 4e8432a0..6748486e 100644
--- a/src/read.c
+++ b/src/read.c
@@ -666,16 +666,16 @@ eval (struct ebuffer *ebuf, int set_default)
 /* Ignore the commands in a rule with no targets.  */
 continue;

+  if (ignoring)
+/* Yep, this is a shell command, and we don't care.  */
+continue;
+
   /* If there is no preceding rule line, don't treat this line
  as a command, even though it begins with a recipe prefix.
  SunOS 4 make appears to behave this way.  */

   if (filenames != 0)
 {
-  if (ignoring)
-/* Yep, this is a shell command, and we don't care.  */
-continue;
-
   if (commands_idx == 0)
 cmds_started = ebuf->floc.lineno;



Plus some tests need to be written of course.

If someone has a thought of something this might break (other than people
indenting their conditionals with the recipe prefix) please let me know
because I can't think of one.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #40942] Load directive breaks Makefiles

[Paul D. Smith]

Update of bug #40942 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #63219 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Medium Effort  

___

Follow-up Comment #4:

I added an implementation but I changed the name to "unload" and reworked
parts of the implementation.

I also created a API/ABI version value but couldn't find a backward-compatible
way to implement it, that I liked.  So, it's a change in the API.  If anyone
has a good idea of a better way to do it please let me know.

It is possible, via preprocessor statements, to implement a loadable module
that will work with both old and new APIs.  But unfortunately modules written
for the old API won't work with the new one.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 too common and its structure is not regular enough.

We could modify the parser so that "else" lines which start with the recipe
prefix are ignored, so "else" that appears inside a recipe wouldn't be in
effect.  The problem with this is that the recipe prefix could be changed and
since we're not actually parsing the code we would not notice:


if FOO
all:
else
.RECIPEPREFIX = >
else
X = y
endif


How do we understand that once the .RECIPEPREFIX is modified, the "else" that
starts with a TAB should not be assumed to be a recipe prefix anymore?

I guess we can just say that it's never OK to indent make processor statements
with a TAB.  If we assume that any "else" (for example) indented with a TAB is
never a make "else" then we shouldn't have this problem.

I think.  I'm not sure how much havoc this would cause for backward
compatibility.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #64129 (project make):

  Status:None => Duplicate  
 Open/Closed:Open => Closed 

___

Follow-up Comment #4:

Duplicate of bug #59093 thanks for looking that up Martin.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63868] Document MAKEFLAGS pitfalls.

[Paul D. Smith]

Update of bug #63868 (project make):

 Summary: Document MAKEFLASG pitfalls. => Document MAKEFLAGS
pitfalls.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64016] Simplify update_goal_chain.

[Paul D. Smith]

Update of bug #64016 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #3:

I pushed this with my different test.  Hope it's OK.  Thanks Dmitry.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #64107 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Medium Effort  

___

Follow-up Comment #3:

Pushed, thanks Dmitry.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64115] make warns about undefined variable GNUMAKEFLAGS

[Paul D. Smith]

Update of bug #64115 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #2:

Pushed, thanks Dmitry.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64124] Use after free in expand_variable_buf.

[Paul D. Smith]

Update of bug #64124 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #3:

Pushed thanks Dmitry.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Follow-up Comment #2, bug #64107 (project make):

This is a good change, thanks!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64016] Simplify update_goal_chain.

[Paul D. Smith]

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 like this:

run_make_test(q!
hello.x::; @#HELPER# -q wait bye.x out $@
bye.x::; @#HELPER# sleep 1 file $@
!,
  '-j2 hello.x bye.x', "sleep 1\nfile bye.x\nhello.x");

?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #64112 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

I'm not sure which "comments in the source code" you're looking at, but that's
not usually a good way to learn the behavior of the software: instead you
should look at the user's manual:
https://www.gnu.org/software/make/manual/html_node/Reference.html (first
paragraph).

No version of make has ever used backslashes to escape make variable
references: you double the '$'; e.g., $$(foo)



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #63686 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
Operating System:None => Any
   Triage Status:None => Medium Effort  

___

Follow-up Comment #14:

I implemented both the --warn option and .WARNINGS variable.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #63990 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #3:

Fixed thanks Dmitry.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #63856 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
Operating System:None => Any
   Fixed Release:None => SCM
   Triage Status:None => Medium Effort  

___

Follow-up Comment #3:

This is great, thanks Dmitry!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #63981 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Component Version:None => 4.4.1  
Operating System:None => Any
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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


which should be enough and is (IMO) clearer.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Update of bug #63867 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up Comment #4:

Pushed a fix for this, thanks for the note.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63984] Error 2133

[Paul D. Smith]

Update of bug #63984 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

There's no information here about what the problem is, closing.

If you think you've found a bug in GNU make, please add details here about it
and I can re-open.

If you're trying to understand your makefile and why it's not working, please
use the help-m...@gnu.org mailing list to get help, not the bug tracker: we
don't run Savannah projects like GitHub projects where all help discussion is
done through the issue tracker.  In Savannah projects (at any rate, in GNU
Make) the bug tracker is for bugs in the project, and problems or help using
the project are discussed in the mailing lists.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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 means every invocation of tar by GNU make will use
these options.

Sorting the release tarball (and the other options here) is something that
people prefer, to allow for reproducible builds etc.

I think it will work better to simply reset these options when generating the
test results tarball, rather than changing the global settings.  I will do
that.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

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:

  

___
Message sent via Savannah
https://savannah.gnu.org/