[bug #63045] Make crashes when makefile keeps the loaded shared object intact.

[Dmitry Goncharov]

URL:
  <https://savannah.gnu.org/bugs/?63045>

 Summary: Make crashes when makefile keeps the loaded shared
object intact.
 Project: make
   Submitter: dgoncharov
   Submitted: Sun 11 Sep 2022 03:13:13 AM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Sun 11 Sep 2022 03:13:13 AM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63045>

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

[bug #63044] Make fails to update .LOADED when the setup routine returns -1.

[Dmitry Goncharov]

Additional Item Attachment, bug #63044 (project make):

File name: sv63044_fix.diff   Size:0 KB


File name: sv63044_test.diff  Size:1 KB




___

Reply to this item at:

  

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

[bug #63044] Make fails to update .LOADED when the setup routine returns -1.

[Dmitry Goncharov]

Follow-up Comment #1, bug #63044 (project make):

Make fails to add a loaded shared object to .LOADED when the shared object
setup routine returns -1.




$ ls
makefile  timer2.c
$ cat timer2.c 
int plugin_is_GPL_compatible;

int
timer2_gmk_setup (void)
{
  return -1;
}
$ gcc -o timer2.so -shared -fPIC timer2.c
$ cat makefile
load timer2.so
$(info .loaded = $(.LOADED))
all:; $(info .loaded = $(.LOADED))
$ make-4.3
.loaded = 
.loaded = 
make-4.3: 'all' is up to date.



___

Reply to this item at:

  

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

[bug #63044] Make fails to update .LOADED when the setup routine returns -1.

[Dmitry Goncharov]

URL:
  <https://savannah.gnu.org/bugs/?63044>

 Summary: Make fails to update .LOADED when the setup routine
returns -1.
 Project: make
   Submitter: dgoncharov
   Submitted: Sun 11 Sep 2022 01:46:28 AM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Sun 11 Sep 2022 01:46:28 AM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63044>

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

Re: New release of GNU make

[Dmitry Goncharov]

On Sun, Sep 4, 2022 at 9:53 AM Paul Smith  wrote:
>
> On Sun, 2022-09-04 at 00:28 +, Martin Dorey wrote:
> > https://git.savannah.gnu.org/cgit/make.git/commit/configure.ac?id=079
> > 3658c09a8f33581dae6dfbe2483ea279e72b1
> >
> > ... imposed a dependency on autoconf 2.71.
>
> I'm not sure if there's a need for this new autoconf version or not, I
> can look at gnulib.  The issue is that I have a version of autoconf and
> that's the only one I test (and build) with.

Most of hosts that i can use don't have 2.71. I usually edit
configure.ac and replace 2.71 with 2.69 in that case.

regards, Dmitry

[bug #62840] make --version in pipe return SIGPIPE

[Dmitry Goncharov]

Follow-up Comment #4, bug #62840 (project make):

Patch sv62840_fix.diff sets stdout to line buffering after --version and
--help are processed, but before make reads makefiles.


___

Reply to this item at:

  

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

[bug #62840] make --version in pipe return SIGPIPE

[Dmitry Goncharov]

Additional Item Attachment, bug #62840 (project make):

File name: sv62840_fix.diff   Size:2 KB




___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[Dmitry Goncharov]

Follow-up Comment #4, bug #62929 (project make):

Given makefile
foo/bar:; @echo $@

and target foo/./bar this changeset sets $@ to foo/bar.

To proceed with this, changes may be needed in addition to the one in the
attachment.
1. same normalization in lookup_file and in main
2. ability to match foo/./bar rule to foo/bar target


___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[Dmitry Goncharov]

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

pmake behaves the same as bmake.


___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[Dmitry Goncharov]

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

i compared gmake, bmake, sun make, sun dmake, sun make in svr4 mode, aix
make.

Given makefile
hello:
@echo $@

gmake treats ./hello, ././hello, ././/hello or .//hello, as hello. $@ has
value hello.
sun make, sun dmake, sun svr4 make treat ./hello, ././hello or ././/hello as
hello. $@ has value hello.

Sun make, sun dmake and sun svr4 make all treat .//hello or .//.///.///hello
as /hello. This is clearly a bug in sun make, dmake and svr4 make.

bmake, aix make treat ./hello, ././hello, ././/hello or .//hello as different
from hello.

Given makefile
foo/bar:
@echo $@

sun make, sun dmake, sun svr4 make treat foo/./bar, foo/././bar or
foo//.//.//bar as foo/bar. $@ has v alue foo/bar.
gmake, bmake, aix make all treat foo/./bar, foo/././bar or foo//.//.//bar as
different from foo/bar.


Given makefile
./hello:
@echo $@

sun make, sun dmake, sun svr4 make all use ./hello rule to build hello
././hello or ././/hello and $@ has value hello.
With this makefile gmake can build ./hello, ././hello or .//.//.//hello and $@
has the value hello.
With this makefile gmake fails to build hello.

bmake, aix make build ./hello and nothing else and $@ has value ./hello.

Given makefile
foo/./bar:
@echo $@

sun make, sun dmake, sun svr4 make all use rule foo/./bar to build foo/bar,
foo/./bar and foo//.//.//bar and $@ has value foo/bar.

With this makefile gmake can build foo/./bar and nothing else and $@ has value
foo/./bar.
bmake, aix make build foo/./bar and nothing else and $@ has value foo/./bar.



___

Reply to this item at:

  

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

Re: False positive "doesn't match the target pattern" error

[Dmitry Goncharov]

On Sat, Aug 20, 2022 at 8:28 PM Masahiro Yamada  wrote:
> build-dirs := . drivers sound net virt arch/x86/pci arch/x86/power lib
> arch/x86/lib
> subdir-modorder := $(addsuffix /.modules.order, $(build-dirs))
> $(sort $(subdir-modorder)): %/.modules.order: %

Can you remove . from build-dirs and add a dedicated rule for .module.order?
E.g.
build-dirs := drivers sound net virt arch/x86/pci arch/x86/power lib
arch/x86/lib
subdir-modorder := $(addsuffix /.modules.order, $(build-dirs))
$(sort $(subdir-modorder)): %/.modules.order: %; @:
.modules.order:; @:


> Make considers 'foo/bar' and 'foo/./bar'
> as different targets.

This is a deficiency in make. i opened
https://savannah.gnu.org/bugs/index.php?62929 and attached a fix.
Thanks for your report.

regards, Dmitry

[bug #62929] Normalize foo/./bar

[Dmitry Goncharov]

Additional Item Attachment, bug #62929 (project make):

File name: sv62929_fix.diff   Size:3 KB


File name: sv62929_test.diff  Size:1 KB




___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[Dmitry Goncharov]

Follow-up Comment #1, bug #62929 (project make):

Make fails to normalize foo/./bar as foo/bar.

The original bug report is here
https://lists.gnu.org/archive/html/bug-make/2022-08/msg00064.html


___

Reply to this item at:

  

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

[bug #62929] Normalize foo/./bar

[Dmitry Goncharov]

URL:
  <https://savannah.gnu.org/bugs/?62929>

 Summary: Normalize foo/./bar
 Project: make
   Submitter: dgoncharov
   Submitted: Sun 21 Aug 2022 03:38:36 AM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Sun 21 Aug 2022 03:38:36 AM UTC By: Dmitry Goncharov 
.








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62929>

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

Re: False positive "doesn't match the target pattern" error

[Dmitry Goncharov]

On Sat, Aug 20, 2022 at 11:36 AM Alejandro Colomar
 wrote:
>  Why does make(1) need to special-case a leading ./ ?

If your makefile has a rule like
foo.x: foo.z; cp $< $@
then make foo.x and make ./foo.x both produce the same file.

regards, Dmitry

Re: False positive "doesn't match the target pattern" error

[Dmitry Goncharov]

On Sat, Aug 20, 2022 at 5:52 AM Masahiro Yamada  wrote:
> I appreciate GNU Make normalize the path
> by removing "./"
>
> This is helpful in some cases, but I think it is a bad side-effect
> in this case.

Is there a reason to treat './foo.x' as different from 'foo.x'?


> If this is a bug, I can file for it.
> Or, any workaround exists?

It is not clear what you need to achieve.
Can you use an explicit rule like
foo.x: foo.z
?
Do you need make to perform a directory search for foo.x and foo.z in
various directories? In this case i'd look for vpath.

regards, Dmitry

[bug #62908] Regression. Double free if jobserver is enabled, but cannot open fifo.

[Dmitry Goncharov]

Additional Item Attachment, bug #62908 (project make):

File name: sv62908_fix.diff   Size:0 KB


File name: sv62908_test.diff  Size:1 KB




___

Reply to this item at:

  

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

[bug #62908] Regression. Double free if jobserver is enabled, but cannot open fifo.

[Dmitry Goncharov]

URL:
  <https://savannah.gnu.org/bugs/?62908>

 Summary: Regression. Double free if jobserver is enabled, but
cannot open fifo.
 Project: make
   Submitter: dgoncharov
   Submitted: Wed 17 Aug 2022 11:45:30 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Wed 17 Aug 2022 11:45:30 PM UTC By: Dmitry Goncharov 
Failure to open a fifo causes make to double free fifo_name







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62908>

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

Re: Some "fun" last weekend

[Dmitry Goncharov]

On Thu, Jul 21, 2022 at 10:23 AM Paul Smith  wrote:
> Instead, any sub-process can look at MAKEFLAGS, see the value of
jobserver-auth, find the name of the pipe, open it, and start to use
it.  If the sub-process doesn't know anything about MAKEFLAGS, it will
never know that the jobserver is relevant.  If the sub-process knows
about it, it can participate.  Everything is up to the sub-process and
nothing is required of the parent make.

There are clearly lots of benefits here.
There is also a change in behavior.
make-4.3 lets the user control (via presence or absence of +) if a particular
sub-process should participate in the jobserver business.
The current master, on the other hand, is "everyting is up to the sub-make".
E.g.
all:; make -C src
In the case of make-4.3 the sub-make does not participate.
In the case of master the sub-make participates.

> Semaphores would be the same: we pass down the NAME of the semaphore,
and each sub-process that cares would use it.  But as I discovered we
can't use semaphores because we don't have a reliable way to create an
event handler that works both with semaphores and with SIGCHLD (that I
could find), other than polling which I don't like.

It is pselect which does not work with a semaphore.
However, it is possible to use a semaphore and sigchld w/o pselect.
i actually built a prototype which uses a posix semaphore. The algorithm is
the same as the original pipe based algorithm, which predates pselect. The only
difference is that in the pipe algorithm the race between
read and sigchld is solved by having sigchld handler close the dup fd. In
this algorithm the race is solved by having sigchld handler post the semaphore.
The difficult part is the free token. If there was no concept of a
free token, then any
sigchld could post the semaphore. However, in the case of the child
that used the
free token, the semaphore should not be posted. This forces tricky
book keeping and
basically renders the whole algorithm as too complex.

> The downside is we need to write code to manage the named pipe
resource.

Another downside is that any unrelated process which has sufficient privileges
(same eid or root) can mess up the named pipe.

regards, Dmitry

Re: Macro arguments

[Dmitry Goncharov]

On Tue, Aug 9, 2022 at 11:56 PM Paul Smith  wrote:
> ...modifying the way all function arguments
> are parsed is something that needs to be carefully considered, if
> nothing else from a backward-compatibility standpoint.

agree.

i added an example to the manual of how to use variable to hide
special characters.
https://savannah.gnu.org/bugs/?62898

regards, Dmitry

[bug #62881] parentheses confuse make parser

[Dmitry Goncharov]

Additional Item Attachment, bug #62881 (project make):

File name: sv62881_test.diff  Size:1 KB


File name: sv62881_fix.diff   Size:0 KB




___

Reply to this item at:

  

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

Re: Macro arguments

[Dmitry Goncharov]

On Tue, Aug 9, 2022 at 10:48 AM Gisle Vanem  wrote:

Thanks for your report.
See here https://savannah.gnu.org/bugs/index.php?62881

regards, Dmitry

[bug #62881] parentheses confuse make parser

[Dmitry Goncharov]

Follow-up Comment #1, bug #62881 (project make):

A user reported the following here
https://lists.gnu.org/archive/html/bug-make/2022-08/msg00017.html


in GNU-make macros. Like in:

   msg = @echo "$(1)"

   ptest_1:
$(call msg, foo (arg1, arg2, arg3))

...



A 'make ptest_1' shows:
   foo (arg1, arg2, arg3)

...


So does a "foo (arg1, arg2, arg3)" becomes one
argument due to the parenthesis or something?


"foo (arg1, arg2, arg3)" indeed becomes one argument due to the parenthesis.
Make needs to chop "foo (arg1, arg2, arg3))" into 3 arguments for 'msg'.
make assumes that any comma after an open parenthesis delimits an argument for
a nested macro. Like in "foo $(arg1, arg2, arg3))".
There is no '$' in this case and make could figure out that the user intended
'foo (arg1' to be the 1st arg, etc.



___

Reply to this item at:

  

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

[bug #62881] parentheses confuse make parser

[Dmitry Goncharov]

URL:
  <https://savannah.gnu.org/bugs/?62881>

 Summary: parentheses confuse make parser
 Project: make
   Submitter: dgoncharov
   Submitted: Tue 09 Aug 2022 07:02:50 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Tue 09 Aug 2022 07:02:50 PM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62881>

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

[bug #62706] Restrict second expansion to targets which are being built.

[Dmitry Goncharov]

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

sv62706_fix2.diff takes care of secondary expanding a prerequisite marked as
intermediate by .SECONDARY or .INTERMEDIATE when an explicit or static pattern
rule builds the prerequisite.
sv62706_test2.diff adds related tests.


___

Reply to this item at:

  

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

[bug #62706] Restrict second expansion to targets which are being built.

[Dmitry Goncharov]

Additional Item Attachment, bug #62706 (project make):

File name: sv62706_fix2.diff  Size:5 KB


File name: sv62706_test2.diff Size:15 KB




___

Reply to this item at:

  

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

Re: New feature: Post-requisites

[Dmitry Goncharov]

On Fri, Jul 22, 2022 at 9:34 AM  wrote:
> In your example, wouldn't the following accomplish the same thing?
>
>
> update-mandb:  $(DESTDIR)$(man3dir)/foo.3 $(DESTDIR)$(man3dir)/bar.3

i'd also be interested in the answer.
Either this traditional syntax specified above, or

$(DESTDIR)$(man3dir)/bar.3: man3/bar.3 | $(DESTDIR)$(man3dir)
$(info INSTALL  $@)
@$(INSTALL_DATA) -T $< $@
@mandb

regards, Dmitry

Re: Some "fun" last weekend

[Dmitry Goncharov]

On Wed, Jul 20, 2022 at 9:33 AM Paul Smith  wrote:
> There are so many ways this can bite people.  The last thing
> GNU make needs IMO is more obscure subtleties.  For example if someone
> writes this:
>
>   NRMAKE = $(MAKE)
>
>   recurse:
>   MAKEFLAGS=$(MAKEFLAGS) $(NRMAKE)
>
> it will break.

Maybe this behavior is useful. When jobserver-auth in MAKEFLAGS
bothers the user a regular advice is to reset MAKEFLAGS or filter out
jobserver-auth. This new behavior does just that. Even though, i
agree, it is very surprising.


> Just to be clear when you say "all the disadvantages of named pipes"
> are you referring to the ones I mentioned in my email, or are there
> other disadvantages that should be considered as well that I didn't
> mention?

The ones that you mentioned.

>  Are you suggesting that we create
> our own implementation of sem_* that works this way?

That and eventfd was an answer to your question "how do we add a
semaphore to select?".
i am not suggesting any of that in make. i actually like the current design.

if we take a step back, what is the problem? The problem is the
presence of jobserver-auth in MAKEFLAGS in the non recursive case.
You already implemented a solution which sets jobserver-auth=-2,-2.
Another option is to remove jobserver-auth from MAKEFLAGS. This would
rob make of a chance to notify the user that the program cannot
participate in the job server protocol, the file descriptors cannot be
opened. That may be better than the subtlety that you described above.
On the other hand, if we were to rewrite the current impl with e.g.
named pipes, the problem of jobserver-auth in MAKEFLAGS would stay,
would it not?


regards, Dmitry

Re: Some "fun" last weekend

[Dmitry Goncharov]

On Tue, Jul 19, 2022 at 6:13 PM Paul Smith  wrote:
> There are at least two Savannah bugs about this very subtle and
> annoying issue.

Do you mean that jobserver-auth is present in the child env, even
though the fds are closed?


> So the first thing I tried to do was to add another setting of the
> --jobserver-auth variable assignment to MAKEFLAGS of the child
> environment if we're not in the "submake context".  So it would look
> like this:
>
>   MAKEFLAGS= --jobserver-auth=2,3 --jobserver-auth=-2,-2
>
> where the "-2,-2" was there to override the original, and this would be
> added only when starting a process that was not a recursive make.
>
> This actually worked pretty well, but it's got some pretty frustrating
> quirks (I think I alluded to these in the Savannah bug).  Mainly,
> because we modify the environment not the value of the make variable,
> when you run this:
>
> all:
> @echo M1=$$MAKEFLAGS
> @echo M2=$(MAKEFLAGS)
>
> you get different output: the environment variable DOES contain the
> extra option, but the make variable does not.  The behavior of these
> things is subtle enough already, it seems unpleasant to make it even
> more complex.

Looks good to me. At least i'd prefer a pipe and this (or similar)
quirk over all the disadvantages of named pipes.


> So the first thing I tried was using POSIX semaphores, since the
> Windows implementation uses Windows semaphores.  They're pretty
> portable and easy to use.  In fact, I completely implemented it before
> I ran into a problem: as you may recall the tricky part of the current
> jobserver implementation is that we need to be able to wait for EITHER
> a child job to exit (SIGCHLD) OR a new job token to appear (currently
> read(2) on a file descriptor).  This required a lot of machinations.
>
> Well, I don't see any possible way to do that kind of thing with
> semaphores.  The are implemented as sem_t* and there's no facility I
> can find that would provide a FD that could be used with pselect() or
> whatever.

If you are willing to have a platform specific impl, then linux has eventfd.
https://man7.org/linux/man-pages/man2/eventfd.2.html.

One portable impl to have a semaphore with a fd is to use a pipe.
sem_init opens a pipe.
sem_post writes one byte to the pipe.
sem_wait blocks on reading one byte from the pipe.

However, any of these still require that the mechanism survives fork and exec.
Named pipes with all their disadvantages survive fork and exec.

regards, Dmitry

[bug #62706] Restrict second expansion to targets which are being built.

[Dmitry Goncharov]

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

Another thought on point 2 above.
Posix contains the following requirement.

"The make utility shall treat all prerequisites as targets themselves and
recursively ensure that they are up-to-date, processing them in the order in
which they appear in the rule."

Should word "processing" here be interpreted as any activity, including
secondary expansion (which posix does not define), needed to bring a
prerequisite up to date?

Secondary expansion of implicit rules in gnu make already satisfied these
requirements. This patch makes explicit and static pattern rules to satisfy as
well.



___

Reply to this item at:

  

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

[bug #62734] Have the test suite set ASAN env to ignore leaks.

[Dmitry Goncharov]

Additional Item Attachment, bug #62734 (project make):

File name: sv62734.diff   Size:0 KB




___

Reply to this item at:

  

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

[bug #62734] Have the test suite set ASAN env to ignore leaks.

[Dmitry Goncharov]

URL:
  <https://savannah.gnu.org/bugs/?62734>

 Summary: Have the test suite set ASAN env to ignore leaks.
 Project: make
   Submitter: dgoncharov
   Submitted: Sat 09 Jul 2022 06:57:40 PM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Sat 09 Jul 2022 06:57:40 PM UTC By: Dmitry Goncharov 
There are known memory leaks in make.
When make is build with ASAN checks enabled, those leaks fail the tests.
This patch sets ASAN env to ignore leaks. This simply makes it easier to run
the test suite with ASAN enabled builds of make.
Once (if ever) those known leaks are removed this commit can be reverted.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62734>

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

[bug #62706] Restrict second expansion to targets which are being built.

[Dmitry Goncharov]

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

This is a more detailed description of point 2 above (2. Causes all
prerequisites to be second expanded in the same order they are being built.)


$ cat makefile
.SECONDEXPANSION:
all: hello.tsk bye.tsk
hello.tsk: $$(info 2nd expansion of prereqs of $$@); $(info $@)
bye.tsk: $$(info 2nd expansion of prereqs of $$@); $(info $@)
$ # this is patched make
$ ~/src/make/l64/make
2nd expansion of prereqs of hello.tsk
hello.tsk
2nd expansion of prereqs of bye.tsk
bye.tsk
make: Nothing to be done for 'all'.
$ # this is make-4.3
$ make
2nd expansion of prereqs of bye.tsk
2nd expansion of prereqs of hello.tsk
hello.tsk
bye.tsk
make: Nothing to be done for `all'.
$


We can see that make-4.3 builds 'hello.tsk' before building
'bye.tsk'. The order of secondary expanding prerequisites is the
opposite, first the prerequisites of 'bye.tsk' are expanded, then the
prerequisites of 'hello.tsk'.

The proposed behavior is to secondary expand the prerequisites of
'hello.tsk", build 'hello.tsk', secondary expand the prerequisites of
'bye.tsk', build 'bye.tsk'.

If however the makefile is changed like

$ cat makefile
.SECONDEXPANSION:
all: $$(info 2nd expansion for all) hello.tsk bye.tsk; $(info $@)
hello.tsk: $$(info 1st 2nd expansion of prereqs of $$@) $$(info 2nd 2nd
expansion of prereqs of $$@); $(info $@)
bye.tsk: $$(info 1st 2nd expansion of prereqs of $$@) $$(info 2nd 2nd
expansion of prereqs of $$@); $(info $@)
$ ~/src/make/l64/make
2nd expansion for all
1st 2nd expansion of prereqs of hello.tsk
2nd 2nd expansion of prereqs of hello.tsk
hello.tsk
1st 2nd expansion of prereqs of bye.tsk
2nd 2nd expansion of prereqs of bye.tsk
bye.tsk
all
make: 'all' is up to date.
$ make
2nd expansion for all
1st 2nd expansion of prereqs of bye.tsk
2nd 2nd expansion of prereqs of bye.tsk
1st 2nd expansion of prereqs of hello.tsk
2nd 2nd expansion of prereqs of hello.tsk
hello.tsk
bye.tsk
all
make: `all' is up to date.
$


Then $$(info 2nd expansion for all) is secondary expanded
before the prerequisites of hello.tsk and bye.tsk are secondary
expanded. The patch keeps this aspect of behavior is intact.



___

Reply to this item at:

  

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

Re: [bug #62706] Restrict second expansion to targets which are being built.

[Dmitry Goncharov]

On Tue, Jul 5, 2022 at 12:34 PM Edward Welbourne  wrote:
> was thinking of the fact that, if you'd started with
>
> all: $$(info 2nd expansion for all) hello.tsk bye.tsk; echo built both
>
> then its info would appear first, although its rule would be run last.

That's correct. $$(info 2nd expansion for all) is secondary expanded
before the prerequisites of hello.tsk and bye.tsk are secondary
expanded.

> I suppose that's unchanged by this patch, though,

Not changed.
This conversation made me realize that the description in the ticker
is not adequate. i'm going to update it. Thanks.

regards, Dmitry

Re: [bug #62706] Restrict second expansion to targets which are being built.

[Dmitry Goncharov]

On Tue, Jul 5, 2022 at 5:19 AM Edward Welbourne  wrote:
>  I would have expected the order to be the exact reverse of the
> order of building:

i guess, an example will make it more clear.

$ cat makefile
.SECONDEXPANSION:
all: hello.tsk bye.tsk
hello.tsk: $$(info 2nd expansion of prereqs of $$@); $(info $@)
bye.tsk: $$(info 2nd expansion of prereqs of $$@); $(info $@)
$ # this is patched make
$ ~/src/make/l64/make
2nd expansion of prereqs of hello.tsk
hello.tsk
2nd expansion of prereqs of bye.tsk
bye.tsk
make: Nothing to be done for 'all'.
$ # this is make-4.3
$ make
2nd expansion of prereqs of bye.tsk
2nd expansion of prereqs of hello.tsk
hello.tsk
bye.tsk
make: Nothing to be done for `all'.
$


You can see that make-4.3 builds 'hello.tsk' before building
'bye.tsk'. The order of secondary expanding prerequisites is the
opposite, first the prerequisites of 'bye.tsk' are expanded, then the
prerequisites of 'hello.tsk'.

The proposed behavior is to secondary expand the prerequisites of
'hello.tsk", build 'hello.tsk', secondary expand the prerequisites of
'bye.tsk', build 'bye.tsk'.

regards, Dmitry

[bug #62706] Restrict second expansion to targets which are being built.

[Dmitry Goncharov]

Follow-up Comment #1, bug #62706 (project make):

Second expand only the prerequisites of the targets being built.
Avoid second expanding the prerequisites of targets which are not being
built.

There are multiple benefits.

1. Avoids redundant work of second expanding prerequisites of the targets
which are not being built.

Example 1

.SECONDEXPANSION:
hello.tsk: $$(info 2nd exp for hello) $$(file https://savannah.gnu.org/bugs/?62706>

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

[bug #62706] Restrict second expansion to targets which are being built.

[Dmitry Goncharov]

Additional Item Attachment, bug #62706 (project make):

File name: sv62706_doc.diff   Size:4 KB


File name: sv62706_test.diff  Size:14 KB


File name: sv62706_fix.diff   Size:5 KB




___

Reply to this item at:

  

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

[bug #62706] Restrict second expansion to targets which are being built.

[Dmitry Goncharov]

URL:
  <https://savannah.gnu.org/bugs/?62706>

 Summary: Restrict second expansion to targets which are being
built.
 Project: make
   Submitter: dgoncharov
   Submitted: Mon 04 Jul 2022 11:19:17 PM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: Any
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Mon 04 Jul 2022 11:19:17 PM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62706>

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

Re: Goodbye to GNU make's "build.sh" ... ?

[Dmitry Goncharov]

On Sun, Jun 26, 2022 at 5:48 PM Paul Smith  wrote:
> Seems like it's not so much that the patch was rejected; indeed they
> seem to agree there's a bug.  But they wanted more work on it and it
> sort of fell apart.  I have no idea how much effort it would be to push
> hard enough to get a change merged.


i think, people use shell globbing much more often than $(wildcard) or
glibc's glob impl.
bash's glob impl is derived from the same old rms impl and has the bug
fixed. And this allows the situation to continue.

regards, Dmitry

Re: Goodbye to GNU make's "build.sh" ... ?

[Dmitry Goncharov]

On Sunday, June 26, 2022, Paul Smith  wrote
>
>
> I would prefer to have that fixed in gnulib, than continue to maintain
> a local copy just to avoid this issue.


Then there is no choice to drop gnulib and build.sh should go.
Since you asked for opinions, my opinion is that maintaining a mini make
along with the real make can complicate the release procedure.
It is not clear that anybody would benefit from a mini make. What was the
original driving force to introduce build.sh?





> Seems like it's not so much that the patch was rejected; indeed they
> seem to agree there's a bug.  But they wanted more work on it and it
> sort of fell apart.  I have no idea how much effort it would be to push
> hard enough to get a change merged.
>
>
>
>
>

Re: Goodbye to GNU make's "build.sh" ... ?

[Dmitry Goncharov]

On Sun, Jun 26, 2022 at 10:11 AM Paul Smith  wrote:
> This really came up because I was trying to find a way to include the
> latest gnulib globbing library.  Adding "glob" to this pulls in a HUGE
> number of prerequisites.

Have you considered to to avoid glob from gnulib? Make has its one
impl of glob which it uses on certain systems.
We could use this impl and maintain it on all systems.
Aside from dependencies, one problem with the gnulib impl of glob is
that it has a bug on some filesystems.
i submitted a patch to both glibc and gnulib.
https://sourceware.org/pipermail/libc-alpha/2017-November/088984.html
and
https://lists.gnu.org/archive/html/bug-gnulib/2019-11/msg6.html.
The code is complex enough that review requires significant effort and
the patch is not merged.
The result is that the gnulib impl, which is supposed to be preferred,
is the only one that has the bug. Code like this
$(wildcard lib/ src/)
works on any system other than gnu (again on some filesystems).

regards, Dmitry

[bug #62650] Fix an incorrect user message.

[Dmitry Goncharov]

Additional Item Attachment, bug #62650 (project make):

File name: sv62650_fix.diff   Size:1 KB


File name: sv62650_test.diff  Size:2 KB




___

Reply to this item at:

  

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

[bug #62650] Fix an incorrect user message.

[Dmitry Goncharov]

URL:
  <https://savannah.gnu.org/bugs/?62650>

 Summary: Fix an incorrect user message.
 Project: make
   Submitter: dgoncharov
   Submitted: Sat 18 Jun 2022 10:13:59 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: Any
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Sat 18 Jun 2022 10:13:59 PM UTC By: Dmitry Goncharov 
Make reports an incorrect message when a file found through directory search
is preferred over the explicitly mentioned file.


$ cat -n makefile
 1  vpath hello.c src
 2  all: hello.c; $(info $@ from $^)
 3  hello.c: ; $(info 1 $@)
 4  src/hello.c: ; $(info 2 $@)
$ make
makefile:3: Recipe was specified for file 'hello.c' at makefile:4,
makefile:3: but 'hello.c' is now considered the same file as 'src/hello.c'.
makefile:3: Recipe for 'src/hello.c' will be ignored in favor of the one for
'hello.c'.
2 src/hello.c
all from src/hello.c
make: 'all' is up to date.


There are two bits of incorrect information in this message.

1. make reports that recipe for 'hello.c' is at makefile:4. Should be
makefile:3.

2. make says that recipe for 'src/hello.c' will be ignored in favor of the one
for 'hello.c'. Actually, make ignores the recipe for 'hello.c' in favor of the
one for 'src/hello.c' and sets $< to 'src/hello.c', rather than 'hello.c' in
the recipe of rule 'all'.


With this patch

makefile:3: Recipe was specified for file 'hello.c' at makefile:3,
makefile:3: but 'hello.c' is now considered the same file as 'src/hello.c'.
makefile:3: Recipe for 'hello.c' will be ignored in favor of the one for
'src/hello.c'.
2 src/hello.c
all from src/hello.c
make: 'all' is up to date.








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62650>

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

[bug #62615] Fix the leaks of file->cmds and file->cmds->commands

[Dmitry Goncharov]

Follow-up Comment #1, bug #62615 (project make):

Paul, can you please ignore this patch?
This bug report is correct, there is a memory leak.
But the patch is not correct. The patch fails to take into account a case when
multiple targets are defined on the same rule. Correctly taking care of
freeing commands in cases like


bye.o hello.o: hello.h; $(info 1 $@ from $^)
hello.o: hello.c; $(info 2 $@ from $^)


requires additional bookkeeping, like reference counters or similar. This
patch does not do any of that. 


___

Reply to this item at:

  

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

[bug #62615] Fix the leaks of file->cmds and file->cmds->commands

[Dmitry Goncharov]

Additional Item Attachment, bug #62615 (project make):

File name: sv62615_fix.diff   Size:1 KB


File name: sv62615_test.diff  Size:1 KB




___

Reply to this item at:

  

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

[bug #62615] Fix the leaks of file->cmds and file->cmds->commands

[Dmitry Goncharov]

URL:
  <https://savannah.gnu.org/bugs/?62615>

 Summary: Fix the leaks of file->cmds and file->cmds->commands
 Project: make
   Submitter: dgoncharov
   Submitted: Sat 11 Jun 2022 01:52:52 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: Any
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Sat 11 Jun 2022 01:52:52 PM UTC By: Dmitry Goncharov 
Makefile like the following causes make to leak
file->cmds along with file->cmds->commands allocated for the 1st hello.o
rule.

+++
all: hello.o
hello.o: hello.h; $(info 1 $@ from $^)
hello.o: hello.c; $(info 2 $@ from $^)


To see the leak build with -fsanitize=leak


$ make
makefile2:5: warning: overriding recipe for target 'hello.o'
makefile2:4: warning: ignoring old recipe for target 'hello.o'
2 hello.o from hello.c hello.h
make: Nothing to be done for 'all'.

=
==13813==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7fb54a09bc9c in __interceptor_malloc
/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/gcc-10.2.0/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x558a7a3aae35 in xmalloc ../src/misc.c:190
#2 0x558a7a3c1923 in record_files ../src/read.c:2011
#3 0x558a7a3b6f0d in eval ../src/read.c:1009
#4 0x558a7a3b2a3c in eval_makefile ../src/read.c:438
#5 0x558a7a3b0a38 in read_all_makefiles ../src/read.c:223
#6 0x558a7a397ff7 in main ../src/main.c:1971
#7 0x7fb54953bc4e in __libc_start_main (/lib64/libc.so.6+0x23c4e)

Indirect leak of 23 byte(s) in 1 object(s) allocated from:
#0 0x7fb54a09bc9c in __interceptor_malloc
/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/gcc-10.2.0/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fb54a04660d in __interceptor_strndup
/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/gcc-10.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:395
#2 0x558a7a3aaf88 in xstrndup ../src/misc.c:252
#3 0x558a7a3c1b07 in record_files ../src/read.c:2015
#4 0x558a7a3b6f0d in eval ../src/read.c:1009
#5 0x558a7a3b2a3c in eval_makefile ../src/read.c:438
#6 0x558a7a3b0a38 in read_all_makefiles ../src/read.c:223
#7 0x558a7a397ff7 in main ../src/main.c:1971
#8 0x7fb54953bc4e in __libc_start_main (/lib64/libc.so.6+0x23c4e)

SUMMARY: AddressSanitizer: 79 byte(s) leaked in 2 allocation(s).








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62615>

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

[bug #62469] Make honors MAKEFLAGS= definition on the command line.

[Dmitry Goncharov]

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

> I'm confident a lot of makefiles do do this, and although it's not a good
idea I don't know that we want to break them.

i agree, that we don't want to break existing makefiles. i also think, that a
build system which relies on a MAKEFLAGS= cli definition is already
broken.


> Also, unfortunately the POSIX spec is not very clear on this point but as
far as I can tell it's not _disallowed_ there which means that it might be a
violation of POSIX.

posix description of makeflags is quite complicated, but as far as i can
decipher it, this piece instructs make to ignore MAKEFLAGS= cli
definition.

"Before the makefile(s) are read, all of the make utility command line macro
definitions (except the MAKEFLAGS macro or the SHELL macro) shall be added to
the environment of make.".

i tested 5 implementations of make.

These are the questions
q1. Does MAKEFLAGS= makefile defn affect topmake behavior?
q2. Does MAKEFLAGS= makefile defn affect submake behavior?
q3. Does MAKEFLAGS= cli defn affect topmake behavior?
q4. Does MAKEFLAGS= cli defn affect submake behavior?

Here are the answers


   q1 q2  q3 q4
sun make   no yes no no
svr4 make  no yes no no
aix make   no yes no no
bmake  no no  no no
gmake  yesyes yesyes



bmake does not honor MAKEFLAGS= defn in the makefile. Instead, bmake
honors .MAKEFLAGS: special target.


> I'll need to think about the best way forward.

i think we can either
1. Keep the current behavior intact and possibly add a warning to the manual
that cli MAKEFLAGS= defn wipes out cli flags.
or
2. Ignore cli MAKEFLAGS= defn. This is what the attached patch does.

i think, we should not legalize MAKEFLAGS= cli definition and should
not add code to allow MAKEFLAGS= cli definition to be merged with cli
flags.



___

Reply to this item at:

  

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

[bug #62514] Regression. make ignores cli flags.

[Dmitry Goncharov]

Additional Item Attachment, bug #62514 (project make):

File name: sv62514_fix.diff   Size:4 KB


File name: sv62514_test.diff  Size:3 KB




___

Reply to this item at:

  

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

[bug #62514] Regression. make ignores cli flags.

[Dmitry Goncharov]

URL:
  <https://savannah.gnu.org/bugs/?62514>

 Summary: Regression. make ignores cli flags.
 Project: make
Submitted by: dgoncharov
Submitted on: Tue 24 May 2022 12:16:45 AM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: Any
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Tue 24 May 2022 12:16:45 AM UTC By: Dmitry Goncharov 
Commit f2771aa614d3a826b70973217c33f605fb4cd0c2 introduced function
reset_switches.
reset_switches wipes out certain flags specified on the command line.

/usr/bin/make is make-4.3.
make is the latest make from git.


$ cat makefile
MAKEFLAGS=-B
all:; $(info MAKEFLAGS=$(MAKEFLAGS))
$ /usr/bin/make -s
MAKEFLAGS=Bs
$ make -s
MAKEFLAGS=B
make: 'all' is up to date.
$


Flag '-s' is missing from MAKEFLAGS.
Also, the last output from make is "make: 'all' is up to date.".
This tells that '-s' is not in effect.
Similarly, reset_switches wipes out certain other options, e.g. -k, -S,
-l, --debug=, etc.
This patch deletes reset_switches and replaces it with a piece of code in
detect_switches to filter out duplicates.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62514>

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

Re: Potential Bug: `.PHONY` targets and order-only prerequisites

[Dmitry Goncharov]

On Sat, May 21, 2022 at 12:25 PM Paul Smith  wrote:
> Maybe what you're saying is that make should throw an error or warning
> if you try to add an order-only prerequisite to a phony target, telling
> you that it will have no effect on your makefile?

Having a phony target depend (usually indirectly, but there are
examples of immediate dependency) on an order-only prerequisite is
quite common. This happens when the top target is marked phony and
there is an order-only prerequisite down the graph.

regards, Dmitry

[bug #62496] Fix "7.3 Conditionals that Test Flags" in the manual,

[Dmitry Goncharov]

Additional Item Attachment, bug #62496 (project make):

File name: sv62496_test.diff  Size:1 KB




___

Reply to this item at:

  

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

[bug #62496] Fix "7.3 Conditionals that Test Flags" in the manual,

[Dmitry Goncharov]

Additional Item Attachment, bug #62496 (project make):

File name: sv62496_doc.diff   Size:1 KB




___

Reply to this item at:

  

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

[bug #62496] Fix "7.3 Conditionals that Test Flags" in the manual,

[Dmitry Goncharov]

URL:
  <https://savannah.gnu.org/bugs/?62496>

 Summary: Fix "7.3 Conditionals that Test Flags" in the
manual,
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 21 May 2022 01:21:51 AM UTC
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Sat 21 May 2022 01:21:51 AM UTC By: Dmitry Goncharov 
In paragraph "7.3 Conditionals that Test Flags" the manual contains the
following recommendation


For example, here is how to arrange to use ‘ranlib -t’ to finish marking
an archive file up to date:

archive.a: …
ifneq (,$(findstring t,$(MAKEFLAGS)))
...



When the user specifies long or -I options, this piece of code specified
above will find 't' when -t was not specified.
E.g.
$ make --no-print-directory -I/tmp
causes MAKEFLAGS to contain '--no-print-directory -I/tmp'.

We can filter out long and -I options with 'filter-out -%'.
E.g.

$(findstring t,$(filter-out -%,$(MAKEFLAGS)))









___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62496>

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

Re: Potential Bug: `.PHONY` targets and order-only prerequisites

[Dmitry Goncharov]

On Wed, May 18, 2022 at 5:37 PM Jacob Kopczynski
 wrote:
>>   - it might make sense to state explicitly that order-only prereqs
>> which are phony behave in all ways like standard prerequisites.

This statement is simply incorrect.
Order-only prerequisites which are phony do not behave like regular
prerequisites.
An order-only prerequisite which is phony is rebuilt every time, but
still does not cause those targets, which depend on this order-only
phony prerequisite, to be rebuilt.

regards, Dmitry

[bug #62469] Make honors MAKEFLAGS= definition on the command line.

[Dmitry Goncharov]

Additional Item Attachment, bug #62469 (project make):

File name: sv62469_doc.diff   Size:1 KB


File name: sv62469_test.diff  Size:2 KB


File name: sv62469_fix.diff   Size:1 KB




___

Reply to this item at:

  

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

[bug #62469] Make honors MAKEFLAGS= definition on the command line.

[Dmitry Goncharov]

URL:
  

 Summary: Make honors MAKEFLAGS= definition on the
command line.
 Project: make
Submitted by: dgoncharov
Submitted on: Mon 16 May 2022 02:12:20 AM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

Make honors MAKEFLAGS= definition on the command line.

Such command line definition wipes out command line switches from the
resultant MAKEFLAGS definition, even though the command line switches are
active.

In this example switch -d is active, but the value of MAKEFLAGS in make's
memory is 'r'.


$ cat makefile 
$(info  at parse time MAKEFLAGS="$(MAKEFLAGS)")
all:;$(infoin a recipe MAKEFLAGS="$(MAKEFLAGS)")
$ /usr/bin/make -d MAKEFLAGS=r
GNU Make 4.3
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Reading makefile 'makefile'...
at parse time MAKEFLAGS="r"
Updating makefiles
 Considering target file 'makefile'.
  Looking for an implicit rule for 'makefile'.
  No implicit rule found for 'makefile'.
  Finished prerequisites of target file 'makefile'.
 No need to remake target 'makefile'.
Updating goal targets
Considering target file 'all'.
 File 'all' does not exist.
 Finished prerequisites of target file 'all'.
Must remake target 'all'.
in a recipe MAKEFLAGS="r"
Successfully remade target file 'all'.
make: 'all' is up to date.


Parent make then passes this incorrect value of MAKEFLAGS to each recursive
child make.

The manual already describes that MAKEFLAGS should only be specified in
makefile or in the environment. E.g. appendix a says
"MAKEFLAGS

The flags given to make. You can set this in the environment or a makefile
to set flags."

and

In 5.7.3 the manual says
"If you do not want to pass the other flags down, you must change the value of
MAKEFLAGS, like this:

subsystem:
cd subdir && $(MAKE) MAKEFLAGS="

The manual does not explicitly describe what happens when MAKEFLAGS= is
defined on the command line.

This patch adds a piece of code which causes make to ignore MAKEFLAGS=
command line argument and print a warning.
This patch also adds a piece of documentation to the manual to explicitly
prohibit MAKEFLAGS= arguments.





___

Reply to this item at:

  

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

Re: Archive Members as Targets

[Dmitry Goncharov]

On Tue, May 10, 2022 at 5:12 PM Michael Lehn  wrote:
> But not on the Linux boxes there make always rebuild everything. On all 
> machines I am using GNU Make.
...
> Can anyone confirm that?

i can confirm that for me on linux the latest make from git as well as
make-4.3 correctly detect that libfoo.a is up to date.
What version of make do you use?

> (or tell me what obvious stupid mistake I have done …?)

you don't really need ranlib any longer.

regards, Dmitry

Re: [bug #62173] Fix test features/archives.

[Dmitry Goncharov]

On Sun, Apr 24, 2022 at 2:48 PM Jeffrey Walton  wrote:
> Be sure to test the change on OpenBSD. In the past OpenBSD needed the
> dash for options. I'm not sure if it is needed nowadays.

The change that was mentioned added the dash. The current default
ARFLAGS=-rv, which is also required by posix.
It is a good idea to test on bsd. i used to have one bsd machine, but
gave it up long ago. Is there a publicly available bsd nowadays?

regards, Dmitry

[bug #62174] fix test functions/shell on aix.

[Dmitry Goncharov]

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

Paul, the changes that were introduced in toplevel to set LANG=C do not have
desired effect, because run_make_tests.pl sets $ERR_command_not_found before
 is called.

Since you didn't like removing LANG from environment, i attached another patch
(sv62174_fix2.diff) which sets LANG=C before $ERR_command_not_found is
initialized.


___

Reply to this item at:

  

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

[bug #62174] fix test functions/shell on aix.

[Dmitry Goncharov]

Additional Item Attachment, bug #62174 (project make):

File name: sv62174_fix2.diff  Size:0 KB




___

Reply to this item at:

  

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

[bug #62173] Fix test features/archives.

[Dmitry Goncharov]

Follow-up Comment #4, bug #62173 (project make):

Paul, a typo was introduced, which causes multiple tests to fail.
Please have a look at sv62173_fix_typo.diff.


___

Reply to this item at:

  

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

[bug #62173] Fix test features/archives.

[Dmitry Goncharov]

Additional Item Attachment, bug #62173 (project make):

File name: sv62173_fix_typo.diff  Size:0 KB




___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

> For one thing it causes a number of tests to fail.
Fixed.

> For another thing the docs explicitly say:
> Note 'make' is smart enough not to add a prerequisite listed in
'.EXTRA_PREREQS' as a prerequisite to itself. 

Does this behavior have to be silent?


Let me present reasons for the message, since you kept the ticket open

1. This example
hello.x: .EXTRA_PREREQS:=hello.x 
has a typo.
This was supposed to be
hello.x: .EXTRA_PREREQS:=hello.y

The user keeps modifying hello.y and running make and make keeps telling the
user hello.x is up to date.
The message would help.

2. The manual says
"‘Circular xxx <- yyy dependency dropped.’

This means that make detected a loop in the dependency graph: after
tracing the prerequisite yyy of target xxx, and its prerequisites, etc., one
of them depended on xxx again.
"

It looks to me that that the user reading this can expect make to report all
cases of circular dependencies.




___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

Additional Item Attachment, bug #60736 (project make):

File name: sv_60736_add_avoid_circular_dep_msg_tests.diff Size:2 KB
   




___

Reply to this item at:

  

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

[bug #62356] Setting -R through MAKEFLAGS should set -r.

[Dmitry Goncharov]

Additional Item Attachment, bug #62356 (project make):

File name: sv62356_test.diff  Size:0 KB


File name: sv62356_fix.diff   Size:0 KB




___

Reply to this item at:

  

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

[bug #62356] Setting -R through MAKEFLAGS should set -r.

[Dmitry Goncharov]

URL:
  

 Summary: Setting -R through MAKEFLAGS should set -r.
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 23 Apr 2022 02:11:17 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

Setting -R through MAKEFLAGS should set -r, just like -R on the command line
sets -r.



$ cat makefile
MAKEFLAGS:=-R
all: hello.o
$ make --debug=implicit 2>&1 |tail -10
Trying implicit prerequisite 'RCS/hello.mod,v'.
Trying pattern rule with stem 'hello.mod'.
Trying implicit prerequisite 'RCS/hello.mod'.
Trying pattern rule with stem 'hello.mod'.
Trying implicit prerequisite 's.hello.mod'.
Trying pattern rule with stem 'hello.mod'.
Trying implicit prerequisite 'SCCS/s.hello.mod'.
   No implicit rule found for 'hello.o'.
  Must remake target 'hello.o'.
make: *** No rule to make target 'hello.o', needed by 'all'.  Stop.
$


Same example with this patch.


$ make --debug=implicit 2>&1 |tail -10
Updating makefiles
Updating goal targets
 File 'all' does not exist.
 Looking for an implicit rule for 'all'.
 No implicit rule found for 'all'.
   File 'hello.o' does not exist.
   Looking for an implicit rule for 'hello.o'.
   No implicit rule found for 'hello.o'.
  Must remake target 'hello.o'.
make: *** No rule to make target 'hello.o', needed by 'all'.  Stop.
$





___

Reply to this item at:

  

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

[bug #62324] Fix cache integrity check

[Dmitry Goncharov]

Additional Item Attachment, bug #62324 (project make):

File name: sv62324_test.diff  Size:2 KB


File name: sv62324_fix.diff   Size:4 KB




___

Reply to this item at:

  

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

[bug #62324] Fix cache integrity check

[Dmitry Goncharov]

URL:
  

 Summary: Fix cache integrity check
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 16 Apr 2022 05:59:23 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:


.SECONDEXPANSION:
all: bye.x
%.x: $$(firstword %.1;



The makefile presented above causes make to fail integrity self check 
   
with the following message
   
  
   
make: *** unterminated call to function 'firstword': missing ')'.  Stop.  
   
make: bye.x: Field 'stem' not cached: bye

This "'stem' not cached" failure happens, because in pattern_search file->stem
is temporarily set to a value for the sake of set_file_variables and reset
afterwords.  However, before file->stem can be reset variable_expand_for_file
is called and it bumps to the syntax error and causes make to perform
integrity self check before exiting. The integrity check fails, because the
stem in question was never cached.
   

This fix adds a dedicated stem parameter to set_file_variables to relieve the
callers from having to modify and then restore file->stem.
  


src/commands.c (set_file_variables): Take second parameter stem to relieve the
callers of set_file_variables from setting and restoring file->stem.
src/commands.h (set_file_variables): Ditto.
(execute_file_commands): Pass file->stem to set_file_variables.   
   
src/file.c (expand_deps): Pass d->stem to set_file_variables and remove no
longer needed code to set and restore file->stem.
src/implicit.c (pattern_search): Pass stem_str to set_file_variables and
remove no longer needed code to set and reset file->stem.
tests/scripts/features/se_explicit: Add new tests.
tests/scripts/features/se_implicit: Ditto.
tests/scripts/features/se_statpat: Ditto.
tests/scripts/variables/automatic: Ditto.




___

Reply to this item at:

  

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

[bug #62278] Fix % substitution in static pattern rules.

[Dmitry Goncharov]

Follow-up Comment #1, bug #62278 (project make):

Tested on 64 and 32 bit linux.


___

Reply to this item at:

  

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

[bug #62278] Fix % substitution in static pattern rules.

[Dmitry Goncharov]

Additional Item Attachment, bug #62278 (project make):

File name: sv62278_test.diff  Size:5 KB


File name: sv62278_fix.diff   Size:2 KB




___

Reply to this item at:

  

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

[bug #62278] Fix % substitution in static pattern rules.

[Dmitry Goncharov]

URL:
  

 Summary: Fix % substitution in static pattern rules.
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 09 Apr 2022 03:30:51 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: Any
   Fixed Release: None
   Triage Status: None

___

Details:

When second expansion is enabled make substitutes all instances of a '%' in
each prerequisite of a static pattern rule.



$ cat makefile 
.SECONDEXPANSION: 
   
all: hello.x
hello.x: %.x: $$(wordlist 1, 99, %_%_%.1 %_%_%.2); $(info $@ from $^)
$ /usr/bin/make 
make: *** No rule to make target 'hello_hello_hello.1', needed by 'hello.x'. 
Stop.


This patch
1. Causes make to substitute only the first instance of '%' in each
prerequisite of a static pattern rule when second expansion is enabled.

So, the example above results in


$ ~/src/gmake/make/l64/make
make: *** No rule to make target 'hello_%_%.1', needed by 'hello.x'.  Stop.


2. Adds a set of tests to verify that stem substitution is the same whether
second expansion is enabled or not.

3. Fixes a memory leak in expand_deps




___

Reply to this item at:

  

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

[bug #62206] Fix % substitution in pattern rules.

[Dmitry Goncharov]

Follow-up Comment #4, bug #62206 (project make):

Such a workaround with 2 rules could be something like


.SECONDEXPANSION:
all: lib/hello.o hello.o
%.o: 3$$*.c; $(info $@ from $<)
lib/%.o: lib/3$$*.c; $(info $@ from $<)



___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #62206] Fix % substitution in pattern rules.

[Dmitry Goncharov]

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

> What I usually do is recommend people use $$* instead of % in secondary
expansion expressions like this as it's more clear and less confusing, and
ends up being the same result.

There are situations where the difference between % and $$* matters.

For example, let us say there are files 3hello.c and lib/3hello.c and the
following makefile.



.SECONDEXPANSION:
all: lib/hello.o hello.o
%.o: 3%.c; $(info $@ from $<)



This makefile allows to build both hello.o from 3hello.c and lib/hello.o from
lib/3hello.c with a single rule.

It is possible to workaround this as well by using two rules lib/%.o: and
%.o:. So, i was thinking maybe fixing this is not worth the effort. On the
other hand, lots of users may not be familiar with make enough to figure this
out. With this patch it just works.


___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #62206] Fix % substitution in pattern rules.

[Dmitry Goncharov]

Follow-up Comment #1, bug #62206 (project make):

Tested on linux, sun and aix, 64 and 32 bits.


___

Reply to this item at:

  

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

[bug #62206] Fix % substitution in pattern rules.

[Dmitry Goncharov]

Additional Item Attachment, bug #62206 (project make):

File name: sv62206_stem_substitution_in_pattern_rules_fix.diff Size:6 KB
   


File name: sv62206_stem_substitution_in_pattern_rules_test.diff Size:4 KB
   




___

Reply to this item at:

  

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

[bug #62206] Fix % substitution in pattern rules.

[Dmitry Goncharov]

URL:
  

 Summary: Fix % substitution in pattern rules.
 Project: make
Submitted by: dgoncharov
Submitted on: Mon 21 Mar 2022 01:04:05 AM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: Any
   Fixed Release: None
   Triage Status: None

___

Details:

Make fails to substitute % with the stem in prerequisites of pattern rules
when second expansion is enabled.

E.g. given makefile


.SECONDEXPANSION: 
   
all: hello.x  
   
%.x: $$(wordlist 1, 99, %.1 %.2) $$(wordlist 1, 99, %.3 %.4); $(info $@ from
$^)


make fails to substitute '%' with 'hello' in '%.2' and '%.4'.

Specifically, make substitutes the first % in each 'word', where 'word' is
determined by get_next_word. In the example above, '$(wordlist 1, 99, %.1
%.2)' and '$(wordlist 1, 99, %.3 %.4)' are such 'words'.




___

Reply to this item at:

  

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

[bug #62173] Fix test features/archives.

[Dmitry Goncharov]

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

The patch contains the following changes

-my $arflags = 'rv';
+my $arflags = '-rv';
+if ($^O eq 'aix') {
+$arflags = "-Xany -rv";
+}


That reason for the first part of the patch, specifically

-my $arflags = 'rv';
+my $arflags = '-rv'

is the following

The test has the following piece of code


$_ = `$ar U$arflags libxx.a a1.o $redir`;
if ($? == 0) {
$arflags = 'Urv';
$arvar = "$arvar ARFLAGS=$arflags";
}


This piece of code causes $arvar contain $arflags.
This happens only when ar supports -U. This is relatively new version of gnu
ar.
Other systems (not only aix) won't have ar support -U and $arvar on those
systems does not contain $arflags. The default value of ARFLAGS builtin in
make was change from 'rv' to -rv' in 0e020bbc24d89592e9ea15f9e8b887a71692eedf.
This makes the test fail on any system where ar does not support -U.

The other part of the patch, specifically

+if ($^O eq 'aix') {
+$arflags = "-Xany -rv";
+}

is indeed aix specific. I originally proposed to use an env var OBJECT_MODE
and keep arflags intact on aix (see sv 59096). But that robs the user of the
ability to override the value.
However, i'd call this change trivial.



> I have quite a few of similar issues with the test suite on MS-Windows, but
I never thought I should make changes non-trivial to the test suite to make
those pseudo-failures pass.  Instead, I eyeball the test diffs to determine
whether the issue is real or not. 

i once had to make a change which affected windows (sv 60774). Once i was able
to build make, i wanted to check that the test suite passes. It did not. i am
not familiar with windows. i'd definitely appreciate if the test suite passed.
Similarly, if you ever have to make a change on sun or aix, etc, you'll
appreciate if the test suite passes.

___

Reply to this item at:

  

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

[bug #62175] Port tests to big endian.

[Dmitry Goncharov]

Additional Item Attachment, bug #62175 (project make):

File name: port_tests_to_big_endian.diff  Size:5 KB
   




___

Reply to this item at:

  

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

[bug #62175] Port tests to big endian.

[Dmitry Goncharov]

URL:
  

 Summary: Port tests to big endian.
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 12 Mar 2022 11:21:32 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

Certain tests assume that make builds prerequisites in a specific order.

E.g. test features/se_explicit.diff.13 assumes that makes builds prerequisite
2.x before 1.x.



features/se_explicit  FAILED (14/18
passed)

4 Tests in 1 Category Failed (See .diff* files in work dir for details) :-(

$ cat work/features/se_explicit.diff
se_explicit.diff.13  se_explicit.diff.14  se_explicit.diff.15 
se_explicit.diff.17
$ cat work/features/se_explicit.diff.13
*** work/features/se_explicit.base.13   Sat Mar 12 16:37:19 2022
--- work/features/se_explicit.log.13Sat Mar 12 16:37:19 2022
***
*** 1,3 
- @=2.x,<=5.z,^=5.z 6.z,+=5.z 6.z 5.z,|=7.z 8.z,?=,*=,%=
  @=1.x,<=1.z,^=1.z 2.z,+=1.z 2.z 2.z,|=3.z 4.z,?=,*=,%=
  make: Nothing to be done for 'all'.
--- 1,3 
  @=1.x,<=1.z,^=1.z 2.z,+=1.z 2.z 2.z,|=3.z 4.z,?=,*=,%=
+ @=2.x,<=5.z,^=5.z 6.z,+=5.z 6.z 5.z,|=7.z 8.z,?=,*=,%=
  make: Nothing to be done for 'all'.
$
$ cat work/features/se_explicit.mk.12

.SECONDEXPANSION:
all: 2.x 1.x
2.x: 5.z 6.z 5.z | 7.z 7.z 8.z
1.x: 1.z 2.z 2.z | 3.z 4.z
2.x 1.x: 9.z $$(info @=$$@,<=$$<,^=$$^,+=$$+,|=$$|,?=$$?,*=$$*,%=$$%) ;
%.z: ;
$

features/se_implicit  FAILED (24/25
passed)

1 Test in 1 Category Failed (See .diff* files in work dir for details) :-(

features/se_implicit  FAILED (24/25
passed)

1 Test in 1 Category Failed (See .diff* files in work dir for details) :-(

$ cat work/features/se_implicit.diff.21
*** work/features/se_implicit.base.21   Sat Mar 12 16:41:59 2022
--- work/features/se_implicit.log.21Sat Mar 12 16:41:59 2022
***
*** 1,3 
- @=2.x,<=5.z,^=5.z 6.z,+=5.z 6.z 5.z,|=7.z 8.z,?=,*=2
  @=1.x,<=1.z,^=1.z 2.z,+=1.z 2.z 2.z,|=3.z 4.z,?=,*=1
  make: Nothing to be done for 'all'.
--- 1,3 
  @=1.x,<=1.z,^=1.z 2.z,+=1.z 2.z 2.z,|=3.z 4.z,?=,*=1
+ @=2.x,<=5.z,^=5.z 6.z,+=5.z 6.z 5.z,|=7.z 8.z,?=,*=2
  make: Nothing to be done for 'all'.
$


This happens, because when second expansion is enabled, snap_deps obtains the
list of prerequisites from hash_dump.
Those filenames hash to different buckets on different architectures and this
causes make to process prerequisites in the order determined by hashing.
i observed these failures on big endian sparc-sun and powerpc-aix


This patch uses prerequisite names intentionally chosen to hash in the same
order on both little and big endian.
Tested on big endian sparc-sun and powerpc-aix and little endian intel-linux,
all in 64 and 32 bit modes.

Some other tests assume that make removes intermediate files in a specific
order.


features/patternrules ... FAILED (26/31
passed)

5 Tests in 1 Category Failed (See .diff* files in work dir for details) :-(

$ cat work/features/patternrules.diff.21
*** work/features/patternrules.base.21  Sat Mar 12 16:36:25 2022
--- work/features/patternrules.log.21   Sat Mar 12 16:36:25 2022
***
*** 1,3 
  touch a.1 a.2
  cat a.1 a.2 >a.4
! rm a.1 a.2
--- 1,3 
  touch a.1 a.2
  cat a.1 a.2 >a.4
! rm a.2 a.1





___

Reply to this item at:

  

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

[bug #62174] fix test functions/shell on aix.

[Dmitry Goncharov]

Additional Item Attachment, bug #62174 (project make):

File name: test_functions_shell_fix_on_aix.diff Size:0 KB
   




___

Reply to this item at:

  

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

[bug #62174] fix test functions/shell on aix.

[Dmitry Goncharov]

URL:
  

 Summary: fix test functions/shell on aix.
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 12 Mar 2022 11:14:40 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

Presence of LANG=en_US in the env causes functions/shell test 8 to fail on
aix.



functions/shell . FAILED (8/9 passed)

1 Test in 1 Category Failed (See .diff* files in work dir for details) :-(

$ cat work/functions/shell.diff.8
*** work/functions/shell.base.8 Sat Mar 12 12:30:35 2022
--- work/functions/shell.log.8  Sat Mar 12 12:30:35 2022
***
*** 1 
! 127: /bin/sh: bad-command:  not found.
--- 1 
! 127: /bin/sh: bad-command:  not found



$ LANG=en_US /bin/sh -c 'bad-command'
/bin/sh: bad-command:  not found.
$ LANG= /bin/sh -c 'bad-command'
/bin/sh: bad-command:  not found





___

Reply to this item at:

  

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

[bug #62173] Fix test features/archives.

[Dmitry Goncharov]

Additional Item Attachment, bug #62173 (project make):

File name: test_features_archive_fix.diff Size:0 KB
   




___

Reply to this item at:

  

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

[bug #62173] Fix test features/archives.

[Dmitry Goncharov]

URL:
  

 Summary: Fix test features/archives.
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 12 Mar 2022 11:11:39 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

features/archives tests fail on aix, because make passes ARFLAGS='-Xany -rv',
the test expects ARFLAGS='rv'.


Clearing work...
Making work dirs...

features/archives ... FAILED (5/12
passed)

7 Tests in 1 Category Failed (See .diff* files in work dir for details) :-(

$ cat work/features/archives.diff
archives.diff archives.diff.10  archives.diff.4   archives.diff.6
archives.diff.1   archives.diff.2   archives.diff.5
$ cat work/features/archives.diff
*** work/features/archives.base Sat Mar 12 12:12:52 2022
--- work/features/archives.log  Sat Mar 12 12:12:52 2022
***
*** 1,3 
! ar rv libxx.a a1.o
  ar: creating an archive file libxx.a
  a - a1.o
--- 1,3 
! ar -Xany -rv libxx.a a1.o
  ar: creating an archive file libxx.a
  a - a1.o



Similary features/archives tests fail on sun, because make passes
ARFLAGS='-rv, the tests expect ARFLAGS='rv'.



features/archives ... FAILED (5/12
passed)

7 Tests in 1 Category Failed (See .diff* files in work dir for details) :-(

$ cat work/features/archives.diff
*** work/features/archives.base Sat Mar 12 12:18:35 2022
--- work/features/archives.log  Sat Mar 12 12:18:35 2022
***
*** 1,4 
! ar rv libxx.a a1.o
  ar: creating libxx.a
  ar: writing libxx.a
  a - a1.o
--- 1,4 
! ar -rv libxx.a a1.o
  ar: creating libxx.a
  ar: writing libxx.a






___

Reply to this item at:

  

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

[bug #62172] Haver options/dash-l test exit greacefully, when getloadavg is not available

[Dmitry Goncharov]

Additional Item Attachment, bug #62172 (project make):

File name: exit_grecefully_when_load_not_supported_fix.diff Size:0 KB
   




___

Reply to this item at:

  

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

[bug #62172] Haver options/dash-l test exit greacefully, when getloadavg is not available

[Dmitry Goncharov]

URL:
  

 Summary: Haver options/dash-l test exit greacefully, when
getloadavg is not available
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 12 Mar 2022 11:07:05 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

Test options/dash-l fails on aix, because getloadavg is not available. The
test exits with 1 which causes the tests driver count it as a failed test.
This patch causes the test to exit gracefully.


options/dash-l .. FAILED (no tests
found!)

0 Tests in 0 Categories Complete ... No Failures :-)
---

With the patch applied


options/dash-l .. N/A

0 Tests in 0 Categories Complete ... No Failures :-)
---




___

Reply to this item at:

  

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

[bug #62171] ARFLAGS violate posix on aix.

[Dmitry Goncharov]

Additional Item Attachment, bug #62171 (project make):

File name: arflags_violate_posix_on_aix_fix.diff Size:0 KB
   




___

Reply to this item at:

  

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

[bug #62171] ARFLAGS violate posix on aix.

[Dmitry Goncharov]

URL:
  

 Summary: ARFLAGS violate posix on aix.
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 12 Mar 2022 11:03:51 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

ARFLAGS violate posix on aix.


targets/POSIX ... FAILED (3/4 passed)

1 Test in 1 Category Failed (See .diff* files in work dir for details) :-(

$ cat work/targets/POSIX.diff.2
*** work/targets/POSIX.base.2   Sat Mar 12 16:26:32 2022
--- work/targets/POSIX.log.2Sat Mar 12 16:26:32 2022
***
*** 1,5 
  AR=ar
! ARFLAGS=-rv
  CC=c99
  CFLAGS=-O1
  FC=fort77
--- 1,5 
  AR=ar
! ARFLAGS=-Xany -rv
  CC=c99
  CFLAGS=-O1
  FC=fort77







___

Reply to this item at:

  

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

[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

[Dmitry Goncharov]

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

A typo, ofcourse should be $$(percent)



percent:=%
$(files) : %.ext : $$(patsubst r$$(percent),$$(percent),$$(lastword $$(subst
.stem., ,$$*)))-prereq


___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #62162] patsubst not working in prerequisites under .SECONDEXPANSION

[Dmitry Goncharov]

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

You can store % in a variable


percent:=%
$(files) : %.ext : $$(patsubst r$(percent),$(percent),$$(lastword $$(subst
.stem., ,$$*)))-prereq


___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

Re: [bug #62118] Fix parsing of command line options -f, --file, --makefile.

[Dmitry Goncharov]

On Sun, Feb 27, 2022 at 6:11 PM Paul D. Smith  wrote:
>
> Update of bug #62118 (project make):
...
> When looking at the test results I noticed that we were leaving the temporary
> files behind if we had to re-exec, because the re-exec'd version of make
> didn't realize they were temporary.
>
> I decided to fix this, rather than apply the changes you provided.  However I
> preserved the tests you wrote.

i actually had a patch for this as well. Most of that patch no longer
matters, because you already fixed this. i opened
https://savannah.gnu.org/bugs/index.php?62145 to fix the remaining
scenario when make still fails to remote the file and attached a test.

regards, Dmitry

[bug #62145] Unlink the stdin temporary file on failure to re-execute.

[Dmitry Goncharov]

Additional Item Attachment, bug #62145 (project make):

File name: sv62145_test.diff  Size:4 KB


File name: sv62145_fix.diff   Size:2 KB




___

Reply to this item at:

  

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

[bug #62145] Unlink the stdin temporary file on failure to re-execute.

[Dmitry Goncharov]

URL:
  

 Summary: Unlink the stdin temporary file on failure to
re-execute.
 Project: make
Submitted by: dgoncharov
Submitted on: Sun 06 Mar 2022 07:36:16 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None

___

Details:

Make creates a temporary file to store the make code read from stdin.
If make needs to re-execute itself and this attempt to re-execute fails, make
neglects to unlink the temporary file.


$ cat makefile
def:; $(info hello world)
$(MAKE_RESTARTS)makefile: force; touch $@ && chmod -x $(MAKE)
force::
$ echo 'all: $(info hello)' | ./make -Rd -f makefile -f- 
GNU Make 4.3.90
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Reading makefile 'makefile'...
Reading makefile '/tmp/GmjNbYoy'...
hello
Updating makefiles
 Considering target file 'makefile'.
   Considering target file 'force'.
File 'force' does not exist.
Looking for an implicit rule for 'force'.
No implicit rule found for 'force'.
Finished prerequisites of target file 'force'.
   Target 'force' is double-colon and has no prerequisites.
   Must remake target 'force'.
   Successfully remade target file 'force'.
  Finished prerequisites of target file 'makefile'.
  Prerequisite 'force' of target 'makefile' does not exist.
 Must remake target 'makefile'.
makefile:2: update target 'makefile' due to: force
touch makefile && chmod -x /tmp/test/./make
Putting child 0x55abdef52870 (makefile) PID 3695 on the chain.
Live child 0x55abdef52870 (makefile) PID 3695 
Reaping winning child 0x55abdef52870 PID 3695 
Removing child 0x55abdef52870 PID 3695 from chain.
 Successfully remade target file 'makefile'.
 Considering target file '/tmp/GmjNbYoy'.
 File '/tmp/GmjNbYoy' was considered already.
Re-executing[1]: /tmp/test/./make -Rd -f makefile --temp-stdin=/tmp/GmjNbYoy
make: /tmp/test/./make: Permission denied
$ ls /tmp/GmjNbYoy
/tmp/GmjNbYoy





___

Reply to this item at:

  

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

[bug #62118] Fix parsing of command line options -f, --file, --makefile.

[Dmitry Goncharov]

Additional Item Attachment, bug #62118 (project make):

File name: sv62118_test.diff  Size:4 KB


File name: sv62118_fix.diff   Size:4 KB




___

Reply to this item at:

  

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

[bug #62118] Fix parsing of command line options -f, --file, --makefile.

[Dmitry Goncharov]

URL:
  

 Summary: Fix parsing of command line options -f, --file,
--makefile.
 Project: make
Submitted by: dgoncharov
Submitted on: Sat 26 Feb 2022 04:52:59 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

Make fails to parse command line options -f, --file, --makefile when there is
a makefile that updates itself and also makefile read from stdin with -f
combined with other options.


$ cat makefile
def:;echo hello world
  
ifeq ($(flavor $(MAKE_RESTARTS)), undefined)
makefile: force
$(info updating makefile)
touch makefile
  
force:
endif
$ printf 'all:; $(info all)' | make --debug=b -Rf- -f makefile def
GNU Make 4.3
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Updating makefiles
updating makefile
touch makefile
Re-executing[1]: make --debug=b -Rf- -f /tmp/GmtbheQ7 def -o/tmp/GmtbheQ7
GNU Make 4.3
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Updating makefiles
Updating goal targets
 File 'def' does not exist.
Must remake target 'def'.
make: *** No rule to make target 'def'.  Stop.
$


Notice

Re-executing[1]: make --debug=b -Rf- -f /tmp/GmtbheQ7 def -o/tmp/GmtbheQ7


Should be

Re-executing[1]: make --debug=b -Rf/tmp/GmuF8N7n -f makefile def
-o/tmp/GmuF8N7n


With the patch applied

$ printf 'all:; $(info all)' | make --debug=b -Rf- -f makefile def
GNU Make 4.3.90
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Updating makefiles
updating makefile
touch makefile
Re-executing[1]: make --debug=b -Rf/tmp/GmuF8N7n -f makefile def
-o/tmp/GmuF8N7n
GNU Make 4.3.90
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Updating makefiles
updating makefile
touch makefile
Updating goal targets
 File 'def' does not exist.
Must remake target 'def'.
echo hello world
hello world
Successfully remade target file 'def'.
$





___

Reply to this item at:

  

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

[bug #62088] Avoid re-exec due to stdin

[Dmitry Goncharov]

Follow-up Comment #1, bug #62088 (project make):

Indeed, the fix for SV 60595 introduced an undesired change, specifically,
causes make to re-execute when make code is read from the standard input.
This is not related to lowdown. No need for any package or makefile to
reproduce. In fact, the following is sufficient


$ printf 'all:; $(info hello)' | make -f -


___

Reply to this item at:

  

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

Re: make re-exec regression in 'make -sf -' mode

[Dmitry Goncharov]

On Sat, Feb 19, 2022 at 4:12 AM Sergei Trofimovich  wrote:

> Noticed the regression on lowdown-0.10.0 upstream package.
...
> Bitsect points at commit 7c4e6b0299 "[SV 60595] Restart
> whenever any makefile is rebuilt".

Thanks for your report.
I opened https://savannah.gnu.org/bugs/index.php?62088 and attached a fix.

regards, Dmitry

[bug #62088] Avoid re-exec due to stdin

[Dmitry Goncharov]

Additional Item Attachment, bug #62088 (project make):

File name: sv62088_fix.diff   Size:0 KB




___

Reply to this item at:

  

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

[bug #62088] Avoid re-exec due to stdin

[Dmitry Goncharov]

URL:
  

 Summary: Avoid re-exec due to stdin
 Project: make
Submitted by: dgoncharov
Submitted on: Sun 20 Feb 2022 01:26:47 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

A user reported the following

"Noticed the regression on lowdown-0.10.0 upstream package.

Here is a complete trigger:

$ printf 'all:\n\techo $(CC)' | make -sf -

[good] GNU make 4.3 works as expected:

$ printf 'all:\n\techo $(CC)' | make -sf -
cc

[bad] GNU make from git loops indefinitely in re-execution:

$ printf 'all:\n\techo $(CC)' | ./make -sf -


Curiously space separation workaround is enough to
get the result:

$ printf 'all:\n\techo $(CC)' | ./make -s -f -
cc

Bitsect points at commit 7c4e6b0299 "[SV 60595] Restart
whenever any makefile is rebuilt"."

The original bug report is here
https://lists.gnu.org/archive/html/bug-make/2022-02/msg00037.html.




___

Reply to this item at:

  

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

Re: Bug in $(shell ...) I can't understand

[Dmitry Goncharov]

On Sun, Feb 6, 2022 at 3:28 PM Paul Smith  wrote:
> Oh.  I see the problem.  If the shell exits with an exit code of 127
> then make's shell function assumes that it failed because the sub-
> process was not found, and it actually writes its output to stderr!!

This behavior is correct, is not it?

$ cat makefile
SHELL:=/badpath/bash
value:=$(shell echo hello world)
all: ; $(info $(value))
$ make >/dev/null
make: /badpath/bash: No such file or directory
$

stdout is redirected to /dev/null, but the user still wants to see
errors. Is not this scenario what stderr was invented for?

On Sun, Feb 6, 2022 at 4:48 PM Paul Smith  wrote:
> I decided this was a bug and changed the behavior for the next release.

What is the new behavior?

regards, Dmitry

[bug #61957] Document the side effect of mentioning a file explicitly.

[Dmitry Goncharov]

Additional Item Attachment, bug #61957 (project make):

File name: sv61957_side_effect_doc.diff   Size:1 KB
   




___

Reply to this item at:

  

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