[bug #57962] make attempts to execute a directory found on PATH

[Paul D. Smith]

Update of bug #57962 (group make):

   Fixed Release:None => 4.4


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #66359] "make" doesnt see the "Makefile.mak" in directory

[Paul D. Smith]

Update of bug #66359 (group make):

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

___

Follow-up Comment #2:

As Martin says, Makefile.mak is not a standard makefile name that GNU Make
will look for.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

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

[Paul D. Smith]

Update of bug #65759 (group 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 think my idea from below about allowing $(MAKE) -$(MAKEFLAGS) is why this
was done.

So, I documented it.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65777] add const misc global RO arrays

[Paul D. Smith]

Update of bug #65777 (group make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM

___

Follow-up Comment #4:

Applied the straightforward parts of these.  Thanks!


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #66268] Messed up error message about a failure to remove an intermediate file.

[Paul D. Smith]

Update of bug #66268 (group make):

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

___

Follow-up Comment #2:

Thanks!


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #66273] An explicitly mentioned file is not intermediate.

[Paul D. Smith]

Update of bug #66273 (group make):

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

___

Follow-up Comment #2:

Thanks Dmitry!


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

[Paul D. Smith]

Update of bug #65908 (group make):

  Item Group: Bug => Enhancement

___

Follow-up Comment #4:


> it would be better that make provides the infos about that line not
mis-matched `endif'.

Sorry but I don't understand what you mean by "that line".  Which line is it
that make should provide info about?


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #66073] $? is set incorrectly in the case of grouped targets.

[Paul D. Smith]

Follow-up Comment #3, bug #66073 (group make):

I don't understand why the previous comment is talking about foo.q.  In what
way would it ever be correct for foo.q to appear in "$?"?  foo.q is one of the
targets and "$?" lists the out of date prerequisites.

Maybe the comment intended to use "foo.r" instead?

I understand what is being requested and it makes sense at some level. 
However I can't reproduce the "desired" behavior in the current version of GNU
Make HEAD.  I used this makefile:

MAKEFLAGS += -rR
.RECIPEPREFIX = >

xfoo: foo.p foo.q
xbar: bar.p bar.q

foo.p foo.q &: foo.r FORCE
> @echo '$$? = $?'
> touch foo.p foo.q

%.p %.q : %.r FORCE
> @echo '$$? = $?'
> touch $*.p $*.q

.PHONY: xfoo xbar FORCE

to combine both makefiles into a single makefile.

Whether or not we see *foo.r* (or *bar.r*) included in the output depends
entirely on which target is touched before we start make and which is not.

For example if I use the original description and touch *foo.p* / *bar.p*
first, then I see the "undesired" behavior for both explicit and pattern
grouped targets:

$ rm -f foo.* bar.* ; touch foo.r bar.r; sleep 1; touch foo.p bar.p; make
xfoo
$? = FORCE
touch foo.p foo.q

$ rm -f foo.* bar.* ; touch foo.r bar.r; sleep 1; touch foo.p bar.p; make
xbar
$? = FORCE
touch bar.p bar.q

If on the other hand I touch *foo.q* / *bar.q* first, I see the "desired"
behavior for both:

$ rm -f foo.* bar.* ; touch foo.r bar.r; sleep 1; touch foo.q bar.q; make
xfoo
$? = foo.r FORCE
touch foo.p foo.q

$ rm -f foo.* bar.* ; touch foo.r bar.r; sleep 1; touch foo.q bar.q; make
xbar
$? = bar.r FORCE
touch bar.p bar.q

Am I missing some important aspect of the original example that was posted?

As far as I can see commit fabb03eac412b5ea19f1a97be31dc8c6fa7fc047 is not
related to this.  It does change the mtime of also-make targets which maybe is
related somehow.

Dmitry's explanation of what is happening is correct.  Whether that's the
right behavior or not, needs to be considered.  Also what would be involved
with changing the behavior.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #66050] add option --shuffle=nosort

[Paul D. Smith]

Follow-up Comment #3, bug #66050 (group make):

I am not a fan having the --shuffle argument modify the behavior of $(wildcard
...) as they are completely disjoint facilities that have nothing to do with
each other.  IMO it will be confusing.

The result of wildcard has swung back and forth between sorted and not sorted
over time.  If there is a need to have an unsorted variation I think we will
have to do something different like add a new function or similar.

But, I don't really understand what the benefit of having an unsorted result
from the wildcard function would be.  The order in which files are returned
from readdir() is famously undefined, so really they COULD be returned in
sorted order or any other order the system chooses.  Since the order is
totally arbitrary, I don't understand what the goal or purpose of preferring
that order is?

I feel like you have a deeper requirement that is not obvious from this
enhancement request, and it would probably be more fruitful to discuss that
deeper requirement directly rather than discussing downstream changes like
this.  We can discuss here, or probably more easily on the bug-make@gnu.org
mailing list.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

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

[Paul D. Smith]

Update of bug #65739 (group make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #66030] --trace only shows the "primary" ($@) target

[Paul D. Smith]

Update of bug #66030 (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 #6:

I modified what make prints so that it shows all targets that will be updated.
 Thanks for the report!


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #66037] An infinite loop with MAKEFLAGS on the command line.

[Paul D. Smith]

Update of bug #66037 (group make):

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

___

Follow-up Comment #2:

I applied this change.  Thanks Dmitry!


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #66018] Recommendation: document .ONESHELL behavior in sections concerning line prefixes [@+-]

[Paul D. Smith]

Update of bug #66018 (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 added a note to those three sections.  Thanks!


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65999] make -d could be more descriptive WRT phony targets

[Paul D. Smith]

Update of bug #65999 (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:

I modified the trace output to use different wording when rebuilding a phony
target.  Thanks for the report!


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65982] make --trace does not explain remade include files

[Paul D. Smith]

Update of bug #65982 (group make):

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

___

Follow-up Comment #4:

I made the doc more clear.  Thanks!


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65917] --dry-run doesn't handle pattern rules with multiple targets correctly

[Paul D. Smith]

Update of bug #65917 (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 pushed a slightly different version of this change, plus a test for this
behavior. Thanks for the report!


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #66030] --trace only shows the "primary" ($@) target

[Paul D. Smith]

Follow-up Comment #5, bug #66030 (group make):

You are talking about what make knows and what, of the things it knows, it
should print in this situation.  I don't disagree with any of that.

I'm talking about what make _actually does today_.  There can be no
disagreement about that, since it does what it does and I know what it does
and what it was intended to do when the code was written :).  It is not
printing the name of the target that the recipe will create.  It is printing
the name of the target that make discovered was out of date, that caused it to
decide to run the recipe.  That's true no matter what kind of rule is being
invoked: explicit rule, pattern rule with a single target pattern, pattern
rule with multiple target patterns, or grouped target explicit rule (in newer
versions).

You are completely correct that make does know more than that, and it could
print more information than that.  It _could_ print the name(s) of the
target(s) that it expects the recipe to create.  But, that's not what it does
currently, and what it does currently is not really a bug in the sense that
it's doing exactly what it what was intended to do when the code was written. 
I do agree that it's a legitimate enhancement that it should print more
details.

That's all I'm trying to say.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #66030] --trace only shows the "primary" ($@) target

[Paul D. Smith]

Follow-up Comment #3, bug #66030 (group make):

I think we are just disagreeing over a matter of technical semantics.

Make is showing the target it is currently considering, and which it
determined to be out of date and so forced make to run the recipe.  In your
example, that target is "foo.h".  The fact that "foo.c" is _also_ updated by
this recipe is not relevant to make, at least not at this time.

I am not saying that the trace messaging should not be enhanced, or that make
doesn't know this information.  All I'm saying is that the above is why make
shows that target (and only that target): that's the target that was
discovered to be out of date and that's what make is showing here.  It is not
showing what targets it thinks the recipe will generate, although obviously in
most cases these are the same thing.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65999] make -d could be more descriptive WRT phony targets

[Paul D. Smith]

Update of bug #65999 (group make):

 Summary: make --debug=makefile could be more descriptive =>
make -d could be more descriptive WRT phony targets


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65999] make --debug=makefile could be more descriptive

[Paul D. Smith]

Follow-up Comment #1, bug #65999 (group make):

Whether or not you specify "makefile" is not relevant for this issue; these
messages are printed while building the normal targets.  In fact they're
printed even with "basic" debug level.

However they can be made more clear I agree.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #66050] add option --shuffle=nosort

[Paul D. Smith]

Follow-up Comment #1, bug #66050 (group make):

I'm sorry but I don't understand this issue.  Can you clarify?

I don't know what the --shuffle option has to do with sorting: shuffled
prerequisites are never sorted (that would go against the entire concept). 
Are you suggesting a way to always build prerequisites in an order sorted by
their name?  I don't see why that would be something people would want or need
in general, but you can get most of that already with the $(sort ...)
function.



___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #66030] --trace only shows the "primary" ($@) target

[Paul D. Smith]

Follow-up Comment #1, bug #66030 (group make):

The purpose of that statement is to tell you why make elects to run that
recipe, not what it thinks that recipe will do.  The reason this line is shown
the way it is, is that foo.h is the target make is trying to build, and foo.h
is the target that make considers to be out of date, and foo.h is the target
that matches the pattern rule.  Make has no idea that it will even attempt to
build foo.c (yet), much less whether foo.c is out of date or not.

In other words make is not trying to build TWO targets, it's just trying to
build one target (at a time).

It could be that the output generated by --trace should be enhanced to be
clear that make expects more than one target to be generated when it invokes
this recipe, but giving details about what targets make thinks a recipe will
generate is beyond the current scope of the --trace option.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #66011] dependencies after a non-existing file are silently ignored

[Paul D. Smith]

Follow-up Comment #6, bug #66011 (group make):

Yes; if you structure your makefile pattern rules as Dmitry suggests (which is
definitely the right way to do it: you really don't want to add "extra"
prerequisites to a pattern rule beyond only the exact prerequisite that its
built from, such as the .c file, since any missing prereqs cause the rule to
not match) and put the "extra" prerequisites in a separate rule, then as I
said it will still fail, but you'll get a more understandable error message.

However, best is to have your makefile be resilient to these kinds of things
automatically so you don't have to worry about any of it.

Consider this method for example:
https://make.mad-scientist.net/papers/advanced-auto-dependency-generation/


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #66011] dependencies after a non-existing file are silently ignored

[Paul D. Smith]

Update of bug #66011 (group make):

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

___

Follow-up Comment #4:

Indeed the prerequisite did attach to the pattern rule, just as the
documentation said that it did.  If it hadn't attached to the pattern rule,
then your pattern rule would have matched.

You are mistaken about what you see when you use "make -d".  The issue is not
that the items after nonexisting.h are ignored.  The issue is that once make
sees nonexisting.h, the pattern rule doesn't match and make goes looking for a
_different_ pattern rule.  Here is some sample output:

 File 'foo.o' does not exist.
 Looking for an implicit rule for 'foo.o'.
  Trying pattern rule '%.o: %.c a.h nonexisting.h c.h Makefile' with stem
'foo'.
  Trying implicit prerequisite 'foo.c'.
  Found 'foo.c'.
  Trying rule prerequisite 'a.h'.
  Found 'a.h'.
  Trying rule prerequisite 'nonexisting.h'.
  Not found 'nonexisting.h'.
  Trying pattern rule '%.o: %.c' with stem 'foo'.
  Trying implicit prerequisite 'foo.c'.
  Found 'foo.c'.
 Found implicit rule '%.o: %.c' for 'foo.o'.

Note carefully that after "Not found 'nonexisting.h'", GNU Make looks at a
completely different rule: the built-in rule to build object files from source
files.  You can run *make -r* to disable the built-in rules, then maybe the
output will be more clear.

Some people think of pattern rules like a C preprocessor macro, where you
expand it and you get a static rule.

But this concept is wrong: a pattern rule is much more like a C++ overloaded
method, where IF all the types match up with the caller then the method is
used, else the compiler will continue looking for some other method to be
used.  If there is no method where the types match up with the caller, then
you have a compiler error.

That's exactly what happens here: make looks for a pattern rule where BOTH (a)
the target matches the pattern, AND (b) _all_ the prerequisites listed in the
rule either exist, or make can discover a way to build them.

If either one of (a) or (b) is not satisfied then the pattern rule does not
match and make continues looking for another pattern rule that will match.  If
make cannot find any pattern rule that matches, then make gives an error
saying it doesn't know how to build the target.

There can be, and often are, many pattern rules for how to build a given
target.  For example you can build an object file from a C source file, C++,
Fortran, assembly, etc.  So make can't just complain about every non-matching
rule.  And by the time make discovers that no rules have matched, it has
forgotten about all the rules that it tried.

Of course it could be possible, with a lot of effort, to remember all the
rules that were tried so that, if everything fails, they could be printed as
part of the error messages, but that effort has not been made and it's not
clear it's worth the effort.

The output of the --debug option should be sufficient to show what happens,
although it does require concentration and/or familiarity to parse it.

Dmitry recommends this formulation:

hello.o: $(HEADERS) Makefile
%.o : %.c
$(CC) $(CFLAGS) -c $<

not because this will work: it will still fail.  He recommends it because in
this situation the error message that make prints will be more understandable.
 This happens because the pattern rule does match (as all the prerequisites
_of the pattern rule_ exist or can be built), but when make goes to try to
build a specific prerequisite of the target nonexisting.h and can't, it will
print a message about that prerequisite not being built, not that there's no
rule to build the object file.

I'm going to close this issue as "Not a Bug" but you can feel free to continue
to discuss things here if the behavior is not clear.  You can also use the
mailing lists such as help-m...@gnu.org if you prefer (that list has a wider
audience).


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65982] make --trace does not explain remade include files

[Paul D. Smith]

Update of bug #65982 (group make):

  Item Group: Bug => Documentation  

___

Follow-up Comment #2:

This is intended behavior.  The docs for the trace option:
https://www.gnu.org/software/make/manual/html_node/Options-Summary.html#index-_002d_002dtrace

say:
> Show tracing information for make execution.
> Using --trace is shorthand for --debug=print,why.

Looking at the --debug option:
https://www.gnu.org/software/make/manual/html_node/Options-Summary.html#index-_002d_002ddebug

You'll see this info:
> m (makefile)
> By default, the above messages are not enabled while trying to remake the
makefiles.
> This option enables messages while rebuilding makefiles, too.
> Note that the ‘all’ option does enable this option.
> This option also enables ‘basic’ messages.

However I see that this documentation is incorrect by using the term "above
messages".  What it really means is "other types of output"; e.g., without
this option none of the debug options are enabled while rebuilding makefiles.

So, if you want to get tracing for makefile rebuilds you need to add that
debug option as well.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

[Paul D. Smith]

Update of bug #65972 (group make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 
Operating System: POSIX-Based => Any

___

Follow-up Comment #7:

I think only admins can close issues, in Savannah.  Thanks for the followup
info!


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

[Paul D. Smith]

Follow-up Comment #4, bug #65972 (group make):

I don't think we will allow "going back" to the old behavior.  That behavior
was just a bug (IMO) and also, your makefile is fragile by relying on it (if
that object file was ever mentioned anywhere else outside of a pattern rule,
it would break).

If my suggestion doesn't work there must be something more subtle going on
that I didn't catch just by reading that specific makefile (I didn't pull the
Git repo or try the build myself).  Hopefully the comment below gives some
tips for how to parse the debug output and things to look for.


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

[Paul D. Smith]

Follow-up Comment #1, bug #65972 (group make):

Unfortunately the output shown in the comment here is not the important part. 
The important part is why make decided that the -test file needs to be
updated, so you need to look at how make processes the target that is being
rebuilt, not the thing that depends on that target.  And, by extracting only
the "Must build" lines you've lost the information about why make decides it
must be rebuilt.

However, the log files attached do provide this information.

Let us consider for example the dmevents-test target, which 4.3 does not
rebuild but 4.4.1 does.

In the 4.3 version we see these results for this target:

 Finished prerequisites of target file 'dmevents-test'.
 Prerequisite 'dmevents.o' of target 'dmevents-test' does not exist.
 Prerequisite 'dmevents.o.wrap' of target 'dmevents-test' does not exist.
 Prerequisite '../libmultipath/devmapper.o' of target 'dmevents-test' does
not exist.
 Prerequisite 'libmultipath.so.0' is older than target 'dmevents-test'.
 Prerequisite '../libmpathutil/libmpathutil.so.0' is older than target
'dmevents-test'.
 Prerequisite '../libmpathcmd/libmpathcmd.so.0' is older than target
'dmevents-test'.
 Prerequisite 'Makefile' is older than target 'dmevents-test'.
No need to remake target 'dmevents-test'.

while in 4.4.1 we see these results:

  Finished prerequisites of target file 'dmevents-test'.
   Prerequisite 'dmevents.o' is newer than target 'dmevents-test'.
   Prerequisite 'dmevents.o.wrap' is newer than target 'dmevents-test'.
   Prerequisite '../libmultipath/devmapper.o' is newer than target
'dmevents-test'.
   Prerequisite 'libmultipath.so.0' is older than target 'dmevents-test'.
   Prerequisite '../libmpathutil/libmpathutil.so.0' is older than target
'dmevents-test'.
   Prerequisite '../libmpathcmd/libmpathcmd.so.0' is older than target
'dmevents-test'.
   Prerequisite 'Makefile' is older than target 'dmevents-test'.
  Must remake target 'dmevents-test'.


Examining the 4.4.1 logs, it appears to me that the important difference is
actually this line:

   Prerequisite '../libmultipath/devmapper.o' is newer than target
'dmevents-test'.

Once this prerequisite is decided to be rebuilt, then all the other
prerequisites, which were considered intermediate due to the .SECONDARY
statement, also must be rebuilt.

So why is this target rebuilt?  Well, it's not marked as intermediate because
it doesn't appear in the OBJS variable, and make knows that we can build a
../libmultipath/devmapper.o from a ../libmulitpath/devmapper.c which does
exist, so this behavior makes sense to me.

In other words, to me it looks like GNU Make 4.3 is wrong and GNU Make 4.4.1
is correct.

Maybe it would help to declare all the object files .SECONDARY, not just the
TEST objects and helpers; e.g., change:

.SECONDARY: $(OBJS)

to something like this:

.SECONDARY: $(OBJS) $(foreach T,$(TESTS),$($T-test_OBJDEPS))

Does that allow it to work the way you want?


___

Reply to this item at:

  

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


signature.asc
Description: PGP signature

[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

[Paul D. Smith]

Follow-up Comment #2, bug #65908 (group make):

You should review this Git patch:

https://public-inbox.org/git/9d14c08ca6cc06cdf8fb4ba33d2470053dca3966.1712591504.git...@ttaylorr.com/

See this section of the GNU Make manual:
> Extra spaces are allowed and ignored at the beginning of the conditional
directive line, but a tab is not allowed.

This has always been true, but in older releases there were some situations in
which it worked to indent with tabs.  In the current Git latest commit this no
longer works.

It's possible we will find a way to preserve the bug fix that we installed
that caused this problem, while still allowing some or most of the previous
support, at least for the time being, before an official release is made.


___

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