[bug #57676] openjdk11 fails to build with make 4.3

[Paul D. Smith]

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

Thanks for the investigation.  I fixed this along the lines of Dmitry's fix
but I think there's no need to recompute name_mtime here: it should be
sufficient to reset the value to 0 so it's recomputed later.

___

Reply to this item at:

  

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

[bug #58836] build.sh is not populated in objects directory when running configure

[Paul D. Smith]

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

I added something to configure.ac to populate the build.sh script in the build
directory, for ease-of-use.

___

Reply to this item at:

  

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

[bug #59169] Add a --debug=why category for the -d/--debug option

[Paul D. Smith]

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

I added this although I reworked it a bit to remove the global trace_flag
altogether, and updated the man page.  I changed the does not exist message to
"target does not exist" to try to be more clear.

David, I just realized I forgot to add your name to the commit message as the
original author :(  So sorry about that... :( :(

___

Reply to this item at:

  

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

[bug #59601] buffer over-read on malformed environment variable

[Paul D. Smith]

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

Thanks Dmitry; I had that fix already in my queue.  I've pushed it to Git now
and it will be in the next release.  Thanks for the report!

___

Reply to this item at:

  

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

[bug #59585] Make with output-sync prints 'fcntl(): Bad file descriptor' on MacOS when output is piped

[Paul D. Smith]

Update of bug #59585 (project make):

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

___

Follow-up Comment #1:

This is a duplicate of bug #52922  Thanks for reporting!

___

Reply to this item at:

  

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

[bug #59584] ifeq with a space after the first open parenthesis

[Paul D. Smith]

Update of bug #59584 (project make):

  Item Group: Bug => Enhancement

___

Follow-up Comment #1:

The reason this happens is that for conditionals, preceding whitespace is
preserved in the left-hand side of the match, while trailing space is ignored.
 Bizarrely, for the right-hand side of the match leading whitespace is ignored
while trailing whitespace is preserved.

This gives the wholly unsupportable result that:


ifeq ( $(foo), $(foo))


is actually _false_, as is this:


ifeq ( $(foo),$(foo) )


while this is true:


ifeq ($(foo) , $(foo))


It's really frustrating to me how many of areas of makefile parsing paid
insufficient attention to this issue of handling leading/trailing space.

It's well-defined in make variable assignment and in MOST other places in
makefiles that leading whitespace is ignored and trailing whitespace is
preserved, but there are various places where this was not done and we keep
running into them bit by bit over time, after decades' worth of makefiles
exist where who knows how many would break if we fixed the syntax to be
consistent.

I always recommend to everyone that they remove all leading/trailing
whitespace in all conditionals, as a simple to remember and always-correct
rule.

I'll leave this open as an enhancement to consider addressing this in some
way.

___

Reply to this item at:

  

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

[bug #59169] Add a --debug=why category for the -d/--debug option

[David Boyce]

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

I'd consider this change too small to require attribution so not to worry!

___

Reply to this item at:

  

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

[bug #59467] --no-print-directory has no effect if command parsing complains about -j options

[Paul D. Smith]

Update of bug #59467 (project make):

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

___

Follow-up Comment #1:

This works properly in GNU make 4.3:


$ (PATH=$HOME/src/make/make-4.3:$PATH; cd /tmp/x14 && make -j4)
make t1
make[1]: Entering directory '/tmp/x14'
make t2 --no-print-directory
t2
make[1]: Leaving directory '/tmp/x14'


I'm going to close this as a dup but update the Fixed Release version in bug
#47752 to say 4.3 instead of 4.2.

Thanks for pointing out this issue!

___

Reply to this item at:

  

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

[bug #47752] --no-print-directory has no effect if command parsing complains about -j options

[Paul D. Smith]

Update of bug #47752 (project make):

  Status:   Duplicate => Fixed  
 Assigned to:None => psmith 
   Fixed Release:None => 4.3


___

Reply to this item at:

  

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

[bug #47752] --no-print-directory has no effect if command parsing complains about -j options

[Paul D. Smith]

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

Turns out that this fix is present in 4.3, not 4.2.  Updated this bug to have
correct metadata.

___

Reply to this item at:

  

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

[bug #54816] $(wildcard ...) function does not report dangling symlinks

[Paul D. Smith]

Update of bug #54816 (project make):

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

___

Follow-up Comment #3:

This issue appears to be resolved by glibc so I'm closing it.

___

Reply to this item at:

  

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

[bug #58961] Document dynamic phony targets.

[Paul D. Smith]

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

The text here seemed to me to be too extended to explain the restriction so I
wrote it like this instead:


+Prerequisites of @code{.PHONY} are always interpreted as literal
+target names, never as patterns (even if they contain @samp{%}
+characters).  To always rebuild a pattern rule consider using a
+``force target'' (@pxref{Force Targets, ,Rules without Recipes or
+Prerequisites}).


Hopefully that is sufficient.

___

Reply to this item at:

  

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

[bug #58960] Fix a typo in the manual

[Paul D. Smith]

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

Thanks!  Fixed.

___

Reply to this item at:

  

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

Re: notes about make docs p 3.5

[Paul Smith]

On Thu, 2020-12-03 at 15:04 +0300, Dmitry wrote:
> > > It'll be very good to have some examples with explanations in the
> > > docs.
> > Maybe so.  Concrete suggestions are easy to discuss, like:
> 
> I think this example would saved me a lot of time.
> 
> make -f mkfile
> 
> content of mkfile:
> 
> all:
> @echo total $(MAKE_RESTARTS) MAKE_RESTARTS
> 
> mkfile: force
> [ x$(MAKE_RESTARTS) = x3 ] || touch mkfile ; sleep 1
> 
> force: ;

I like to show useful things that people might want to do in the make
manual examples.  I'm not sure what the above makefile is trying to
accomplish nor why one would want to do something like it.  Also there
are a lot of more advanced concepts here like 'force:' etc.: it's
better to work with only one concept at a time if possible.

Maybe if you described the thing you were trying to accomplish or
understand, and what about the documentation made this difficult, we
could come up with a practical example or improve the documentation.

In the SO question you quote it seems like the real confusion stemmed
from other things, not related to remaking makefiles at all; for
example, the fact that a target with no prerequisites is always up to
date if the file exists and so the included makefile would never be
rebuilt if it exists, or that continuously trying to make a file up to
date could run into system limitations with timestamps.

In other words, your question seemed to be trying to force make to
constantly rebuild makefiles in an infinite loop and that was not
successful and the manual didn't explain why that should be.  But the
reasons for why it didn't rebuild forever are mostly pretty esoteric
and system-specific, and to my mind don't really belong in the user's
manual.

In a real makefile no one would ever want to force their included files
to be rebuilt forever for example, and they would not run into the
issues in that SO question.

> For me  (as a  nube in make) would be good something like this:
> Automatic creation of makefile currently possible from only RCS /
> SCCS systems ( more about "Built-In Rules" here -
> https://www.gnu.org/software/make/manual/make.html#Catalogue-of-Rules
>  ).

It's not that it's only possible from RCS or SCCS per se.

It's that make only has built-in rules that know how to check out a
makefile from RCS and SCCS.

If you don't have any makefile already, which is the situation this
paragraph is talking about, then all you have are the default rules
that are built into make: without a makefile you can't define your own
custom rules.

In modern source control systems you don't have the same use for this
behavior.  When you obtain a workspace you already have all the code
checked out, not an empty directory, and it's not really appropriate to
automatically obtain a newer version of the Makefile from source
control: users want to handle that themselves.

So, it's unlikely that there will be a desire to add built-in rules for
more kinds of source control systems.  Probably this paragraph could be
reworked or even mostly removed.

Re: GNU Make 4.3: Makefile rule spooky action at a distance

[Paul Smith]

On Sun, 2020-10-04 at 09:11 +0200, Danny Milosavljevic wrote:
> I just got a build failure in lz4.  I've isolated it and made a
> minimal test case, see below.
> 
> This is on GNU Guix on a x86_64 machine.
> 
> The reason is that apparently one Makefile rule can unwittingly
> change how another unrelated rule functions, IF a submake is
> involved.

This is currently working as expected with the Git HEAD version of GNU
make.  Thanks for Dmitry filing an issue in Savannah and providing some
sample fixes.

https://savannah.gnu.org/bugs/?59230

Re: [PATCH 2/2 V2] * doc/make.texi: Document the let function

[Paul Smith]

On Sat, 2020-10-10 at 17:50 -0500, Pete Dietl wrote:
> Also, I ran ‘’make html”, but it doesn’t look like it does on he
> website. Does anyone know how I can build the docs to look like the
> website locally? 

It's not so easy to do unfortunately.

It requires a bunch of prerequisites, that are needed for anyone who
wants to do real development (from Git) on GNU make.  If you have the
checked-out Git code you will find a file README.git which contains
some useful information.

There is also a makefile "maintMakefile" that contains a whole passel
of maintainer rules.  Among them is a target "gendocs" which will check
out the various HTML boilerplate and CSS content from GNU source
control and run various scripts to generate the documentation.

In order to do this you will need to get a number of things such as
gnulib, texinfo, and CVS (the older GNU projects like the doc
boilerplate use CVS).

Re: [PATCH 1/2] * src/function.c: Introduce the 'let' built-in function

[Paul Smith]

On Fri, 2020-10-23 at 09:14 -0400, Paul Smith wrote:
> On Fri, 2020-10-09 at 16:36 +0200, Jouke Witteveen wrote:
> 
> > This was sent before at the end of last year. Meanwhile, the
> > copyright of my contributions is assigned to the FSF, so I picked
> > this up again and added some documentation (next patch).
> 
> Sorry for the delay.

This new feature has been pushed.  I tweaked some of the documentation,
hopefully for the better, and added a few tests.

Thanks for your work, Jouke!

[bug #51286] Support for additional local make variables

[Paul D. Smith]

Update of bug #51286 (project make):

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

___

Follow-up Comment #4:

These changes have been pushed.

___

Reply to this item at:

  

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

[bug #58656] Cannot handle over 2GB file on Windows

[Paul D. Smith]

Follow-up Comment #3, bug #58656 (project make):

@eliz did you have any comments on the second form of this patch or should I
apply it?

Cheers!

___

Reply to this item at:

  

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

[bug #58639] Shortest stem not matched

[Paul D. Smith]

Follow-up Comment #3, bug #58639 (project make):

I changed the text like this; hopefully it's more understandable now:


 target pattern that matches the file name, @emph{and} all
 prerequisites in that rule either exist or can be built.  The rules
 you write take precedence over those that are built in. Note however,
-that a rule whose prerequisites actually exist or are mentioned always
-takes priority over a rule with prerequisites that must be made by
-chaining other implicit rules.
+that a rule which can be satisfied without chaining other implicit
+rules (for example, one which has no prerequisites or its
+prerequisites already exist or are mentioned) always takes priority
+over a rule with prerequisites that must be made by chaining other
+implicit rules.


___

Reply to this item at:

  

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