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

[Dmitry Goncharov]

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

- is a valid filename.
i think, everybody would be better off, with one and only one syntax of having
make read from stdin.


___

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 #5, bug #60736 (group make):

Attached an alternative patch to
https://savannah.gnu.org/bugs/index.php?65739.


___

Reply to this item at:

  

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

Re: Treat "Circular dependency...dropped" as a hard error instead?

[Dmitry Goncharov]

On Wed, May 8, 2024 at 2:04 PM JZB  wrote:
>
> I have a GNU make-based build system wherein I would like for any/all
> GNU make-detected circular dependencies to be treated as a hard error,
> i.e., fail [immediately], rather than a "dropped and we go on without
> it..." situation.
>
> Is there a way to do this already?

I think, that's a good idea.
i added two patches which implement this ability.
You'll need to wait for make with the patches to be released or apply
the patches yourself.
See https://savannah.gnu.org/bugs/index.php?65739.

regards, Dmitry

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

[Dmitry Goncharov]

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

Here is an example


$ cat makefile
hello: hello
$ make
make: circular hello <- hello dependency dropped
make: Nothing to be done for 'hello'.
$ make --warn=circular-dep:ignore
make: Nothing to be done for 'hello'.
$ make --warn=circular-dep:error 
make: *** circular hello <- hello dependency dropped.  Stop.
$ echo $?
2




___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

Additional Item Attachment, bug #65739 (group make):

File name: sv65739_circular_dep_warn_part1.diff Size: 6KiB
   


File name: sv65739_circular_dep_warn_part2.diff Size: 6KiB
   



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-0329bc976c56c39d462c6cc5223a9b3c843a6486.tar.gz


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

Patch sv65739_circular_dep_warn_part1.diff adds warning
circular-dep. This warning controls how makes handles circular dependencies.
The behavior is to silently drop the dependency, print a message or print a
message
and exit with an error code.
The default behavior is to print a message.

Patch sv65739_circular_dep_warn_part2.diff adds warning
circular-extra-dep. This warning is similar to circular-dep.
circular-extra-dep controls handling of circular dependencies caused by
.EXTRA_PREREQS.

This changeset is split to two commits to allow for dedicated commit messages
and provides ability to revert one of the commits, if needed.

The original user request can be found here
https://lists.gnu.org/archive/html/bug-make/2024-05/msg00013.html.



___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

 Summary: Add warnings circular-dep and circular-extra-dep.
   Group: make
   Submitter: dgoncharov
   Submitted: Tue 14 May 2024 01:40:55 AM 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: Tue 14 May 2024 01:40:55 AM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

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

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

Re: Treat "Circular dependency...dropped" as a hard error instead?

[Dmitry Goncharov]

On Wed, May 8, 2024 at 2:04 PM JZB  wrote:
>... perhaps a command line option or a ".CIRCULARERROR:" rule
> or some way to allow this to be turned on by those who need it?

There is currently no mechanism (option or otherwise) to fail on a
circular dependency.
On top of that, there are situations when make drops a circular
dependency silently.
See https://savannah.gnu.org/bugs/?60736.


regards, Dmitry

Re: idea: make --show-interpretation

[Dmitry Goncharov]

On Mon, May 6, 2024 at 8:26 PM Dan Jacobson  wrote:
> Have a command that reads in a makefile and outputs the makefile saying
> what each part evaluated to.

i'd use -p and -n switches.

regards, Dmitry

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

[Dmitry Goncharov]

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


>  The way I remember it is that if we see a valid jobserver-auth argument, we
ignore the value of -j.

My understanding was that we ignore -j that comes from MAKEFLAGS, we still
honor -j specified on the command line.

> I wonder if we should simply keep the same behavior for both; if we see a
jobserver-auth on the command line we also ignore -j.

My concern is that ignoring -j specified on the command line would cause the
submake in the following example run within the parent jobserver.


all:; $(MAKE) $(MFLAGS) -j3




___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

Make adds '-j' to MAKEFLAGS and MFLAGS when -j is specified on the command
line.
When MFLAGS that contains -j is expanded in a recipe, the submake gets -j as
a command line switch. This causes submake to start its own jobserver and the
submake no longer participates in the parent jobserver.


$ ls
makefile  makefile2
$ cat makefile 
all:; $(MAKE) -fmakefile2 $(MFLAGS)
$ cat makefile2
all:;:
$ make --no-print-directory -j4
make -fmakefile2 -j4 --jobserver-auth=3,4 --no-print-directory
make[1]: warning: -j4 forced in submake: resetting jobserver mode.
:


This was recently reported to the bash mailing list.
https://lists.gnu.org/archive/html/bug-bash/2024-04/msg00078.html.

Submakes don't need -j to participate in the top make's jobserver.
The obvious temptation is to keep MAKEFLAGS and MFLAGS free of -j.
However, -j needs to stay in MAKEFLAGS to allow makefiles to append -j to
MAKEFLAGS.
E.g. the following code needs -j in MAKEFLAGS.


MAKEFLAGS+=-j2


This patch modifies make to avoid -j in MFLAGS.
This patch keeps MAKEFLAGS intact.
Ofcourse, if the user explicitly expands MAKEFLAGS in a recipe they are back
to
the quare one. Explicitly expanding MFLAGS in a recipe is legalized in the
make manual, but explicitly expanding MAKEFLAGS is not. On top of that
explicitly expanding MAKEFLAGS has other isses, see
https://savannah.gnu.org/bugs/?62469.



___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

Additional Item Attachment, bug #65685 (group make):

File name: sv65685_part1.diff Size: 23KiB


File name: sv65685_part2.diff Size: 5KiB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-caa52dc0f3fa3d0ef394065c00d653c139eb10e8.tar.gz


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

 Summary: Submake starts its own jobserver when its recipe
contains $(MAKE) $(MFLAGS) 
   Group: make
   Submitter: dgoncharov
   Submitted: Sat 04 May 2024 08:57:53 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: Sat 04 May 2024 08:57:53 PM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

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

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

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

[Dmitry Goncharov]

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

Indeed. Thank you. job.c changed.

Paul, do you think we can switch to git branches? i can maintain a branch
until merge. i suspect, working with a branch can be easier, than if i attach
different versions of a patch.


___

Reply to this item at:

  

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

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

[Dmitry Goncharov]

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

sv65588_part1.diff and sv65588_part2.diff fix the buffer overflow.
Make (with sv65588_part1.diff and sv65588_part2.diff applied) behaves
differently in oneshell mode compared to when .ONESHELL is not specified.
Specifically when .ONESHELL is not specified and shellflags carries an
unterminated quote, make switches to the slow mode to have the shell deal with
the
quote.


$ ls
makefile
$ cat makefile 
.SHELLFLAGS:=hello'
all:;:
$ 
$ 
$ make
:
/bin/sh: 1: Syntax error: Unterminated quoted string
make: *** [makefile:2: all] Error 2


When .ONESHELL is specified, make (with sv65588_part1.diff and
sv65588_part2.diff applied) proceeds to run the job regardless of the
unterminated quote.


$ cat makefile
.ONESHELL:
.SHELLFLAGS:=hello'
all:;:
$ make
:
/bin/sh: 0: cannot open hello': No such file
make: *** [makefile:3: all] Error 2



sv65588_part3.diff modifies construct_command_argv_internal to have oneshell
mode handle an unterminated quote the same as when .ONESHELL is not
specified.

Tested on linux, sunos and aix, all 64 and 32 bits.



___

Reply to this item at:

  

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

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

[Dmitry Goncharov]

Additional Item Attachment, bug #65588 (group make):

File name: sv65588_part3.diff Size: 5KiB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-758ecd5172e512b667882c3f5b73d7b5e9a30eb0.tar.gz


___

Reply to this item at:

  

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

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

[Dmitry Goncharov]

On Fri, Apr 19, 2024 at 1:42 PM Paul Smith  wrote:
> The main advantages to alloca are twofold:
>
> 1) efficiency for small local buffers, which GNU Make uses a lot.
>
> 2) simplification of the code because you don't have to track this
> memory and ensure it's freed regardless of how the function returns.

Dennis, do you see an alternative that is at least equally efficient,
simple and portable?
One alternative that is equally efficient and simple is variable length arrays.
However, there is a question about portability of vla vs alloca.

regards, Dmitry

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

[Dmitry Goncharov]

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

Other functions are not present in .FEATURES as well. There is really only
guile.


___

Reply to this item at:

  

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

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

[Dmitry Goncharov]

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

A buffer overflow occurs in oneshell mode when shellflags contains characters
special to shell.


$ cat makefile
.ONESHELL:
.SHELLFLAGS:=hello'
all:;:
$ make
Aborted (core dumped)


In oneshell mode construct_command_argv_internal wants to store in argv[0]
the value of shell, followed by shellflags, followed by the command line.
construct_command_argv_internal preallocates memory with

nextp = new_argv[0] = xmalloc (shell_len + sflags_len + line_len + 3);

construct_command_argv_internal is then used recursively to construct argv
from
shellflags.  If shellflags contains characters special to shell, then this
recursive call does the so-called slow mode and constructs argv of "/bin/sh",
"-c", and the value of shellflags.
One problem is that the top construct_command_argv_internal never allocated
room for the "/bin/sh" and "-c".

Aside from the overflow, it is incorrect to prepend "/bin/sh" and "-c" to
shellflags. Preallocating more room in top construct_command_argv_internal
can
solve the overflow, but the resultant command line stays incorrect, because
shellflags were not supposed to carry "/bin/sh" and "-c".

This fix parses shellflags without help from construct_command_argv_internal
and lets shellflags carry quoted tokens in oneshell mode, even when special
characters are present.

The fix is split to 2 parts to simplify review.
Part1 is refactoring which allows to avoid multiple redundant if checks.
Part2 is the actual fix and is supposed to be applied after part1.

Tested on linux-x86, sunos-sparc and aix-powerpc, all 64 and 32 bits.



___

Reply to this item at:

  

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

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

[Dmitry Goncharov]

Additional Item Attachment, bug #65588 (group make):

File name: sv65588_part1.diff Size: 5KiB


File name: sv65588_part2.diff Size: 104KiB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-4448d8da181e3133acac16b178e98513aa6405cd.tar.gz


___

Reply to this item at:

  

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

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

[Dmitry Goncharov]

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

 Summary: A buffer overrun in handling of .SHELLFLAGS.
   Group: make
   Submitter: dgoncharov
   Submitted: Sat 13 Apr 2024 02:13:34 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: Sat 13 Apr 2024 02:13:34 PM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

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

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

Re: A question about submitting a new source code file

[Dmitry Goncharov]

Good morning, Paul.

Thanks for the explanation.

On Sun, Apr 7, 2024 at 8:08 AM Paul Smith  wrote:
> In short, if you create a new file and assign it to the FSF then you
> can still do whatever you want with that file, including even use a
> completely proprietary license for it.

i am intending to include that file to a library of mine which is
released under the bsd license.
Usually, souch source code file would contain something like
/*
 * Copyright (c) 2017 Dmitry Goncharov
 *
 * Distributed under the BSD License.
 * (See accompanying file COPYING).
 */

Do i understand it correctly, that in my copy of this new file that is
assigned to the FSF, i'll remove the
copyright part and the header becomes
/*
 * Distributed under the BSD License.
 * (See accompanying file COPYING).
 */
and whoever is using that library can keep using it under the BSD license?

regards, Dmitry

A question about submitting a new source code file

[Dmitry Goncharov]

Good morning.

Paul, i'd like to contribute another bugfix which involves a brand new
source code file. i will assign the ownership to fsf, if needed.
However, i'd like to be able to use that source file in my other
projects, which are not gpl. i have seen other gnu projects including
public domain code. What is your take on this? Do you think a file can
be included in make, if i made it public domain?
Ofcourse, any answer of yours does not mean that the file will be
included. Inclusion will be subject to the usual review.

regards, Dmitry

Re: A question about hasing in idutils

[Dmitry Goncharov]

> It should be easy to fix: swap the bytes in sum_get_unaligned_32.

Thanks for the pointer, Andreas.
Will try it out.

regards, Dmitry

Re: A question about hasing in idutils

[Dmitry Goncharov]

Thank you for a quick response, Greg.

On Tue, Mar 26, 2024 at 4:56 PM Greg McGary  wrote:
> The code makes no effort to be endian-independent because it is written
> for in-memory hashing on a uniprocessor or homogeneous multiprocessor.

Do you know of a specific difficulty of making that hashing endian-independent?

> Why do the hash keys and table layout need to be consistent across
> heterogeneous architectures?

In the gnu make there were occurrences when a change was introduced,
along with a unit test, and tested on little endian.
Later, someone would run the test on big endian and find out that the
test fails, because the test expects make to do something (e.g. remove
temporary files or print targets) in a certain order, and on big
endian the order turns out to be different due to hashing.
We'd then fix the test some way or another, until another occurrence.
So, in the end hashing works well in gnu make. This difference just
introduces unnecessary maintenance work.

regards, Dmitry

A question about hasing in idutils

[Dmitry Goncharov]

Good morning.

The hash table from id utils from imported to gnu make.
This hash table hashes the same string to different brackets on little
and big endian.
Can you please shed some light why there needs to be this difference
in hashing on little and big endian?

regards, Dmitry

[bug #65438] Sort print-targets output.

[Dmitry Goncharov]

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


> Regarding the hashing vs. endianness, I don't know.

What do you think of changing hashing to produce the same result on little and
big endian?


> Regarding sorting, doesn't this basically mean just using strcmp (or a
small
> wrapper around it) as the sorting function?

strcmp directly cannot be used, because the qsort comparison routine takes
pointers to struct file.
The impl in the attached patch contains function filecmp. filecmp can be
reduced to


static int
filecmp (const void *slotx, const void *sloty)
{
  const struct file *x = *(const struct file **) slotx;
  const struct file *y = *(const struct file **) sloty;
  return strcmp (x->name, y->name);
}


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

Moreover make should not reimplement all the abilities of gnu sort (for
example).
On the other hand, the user won't be able to produce the output in the order
proposed in the patch, unless make produces it.


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

i was thinking of the fact most users run and test make on little endian. This
results in occasional breakage like this one.
As long as there is this difference in hashing, such breakage is likely to
recur.



___

Reply to this item at:

  

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

[bug #65438] Sort print-targets output.

[Dmitry Goncharov]

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


> I doubt most users will be able to map the output they see onto the input
make reads except in simple situations.  When you start having lots of include
files etc. it becomes hard to follow.

i was looking for some useful simple deterministic sorting criteria. This
order was the simplest and possibly useful.
i also considered printing all targets from a makefile before printing targets
from another makefile. However, this requires that make remembers
makefile:lineno of the rules without recipes. This additional requirement
caused me to reject the idea.


> Question: why not just _actually_ sort the output so the results are ordered
by pathname of the target instead of by order discovered?
I also considered sorting by pathname and could not see user benefits to
justify the extra code.
Would be good if those gentlemen who wanted the feature gave their input.

Another option is to abandon the patch and choose names in the test such that
the targets are hashed in the same order on both little and big endian.
Do you know why the current impl has to hash differently on little and big
endian?


___

Reply to this item at:

  

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

[bug #65438] Sort print-targets output.

[Dmitry Goncharov]

Additional Item Attachment, bug #65438 (group make):

File name: sv65438_fix.diff   Size:6 KB


File name: sv65438_test.diff  Size:3 KB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-04b18e1179b14c0ef710c8e9c8e59d1e4bcd7bd0.tar.gz


___

Reply to this item at:

  

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

[bug #65438] Sort print-targets output.

[Dmitry Goncharov]

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

Sort print-targets output.

print-targets prints the targets in the order they ended up hashed in the
table.
The hashing routine hashes differently on big and little endian machines.
The result is that the test fails on big endian machines.

This is an example of the difference.

$ cat work/options/print-targets/t001.diff
*** t001.base   Wed Feb 14 21:41:32 2024
--- t001.logWed Feb 14 21:41:32 2024
***
*** 1,5 
  submake
- .x.z
- always
  all
  goodfile
--- 1,5 
  submake
  all
+ always
  goodfile
+ .x.z


The patch in the attachment sorts the targets by the order in which make
entered those files.
This gets the tests fixed on big endian.
Another benefit is that the sorted output is, in my opinion, friendlier to
humans.



This is the output in make's source code directory produced by make with this
patch.



Makefile
all
all-recursive
am--refresh
../Makefile.in
../configure
../src/config.h.in
../aclocal.m4
../m4/00gnulib.m4
../m4/acinclude.m4
../m4/alloca.m4
../m4/asm-underscore.m4
../m4/c-bool.m4
../m4/dospaths.m4
../m4/eaccess.m4
../m4/extensions.m4
../m4/findprog-in.m4
../m4/getloadavg.m4
../m4/gettext.m4
../m4/gnulib-common.m4
../m4/gnulib-comp.m4
../m4/host-cpu-c-abi.m4
../m4/iconv.m4
../m4/intlmacosx.m4
../m4/largefile.m4
../m4/lib-ld.m4
../m4/lib-link.m4
../m4/lib-prefix.m4
../m4/longlong.m4
../m4/nls.m4
../m4/po.m4
../m4/progtest.m4
../m4/sig_atomic_t.m4
../m4/warn-on-use.m4
../m4/zzgnulib.m4
../configure.ac
src/stamp-h1
config.status
distclean-hdr
build.cfg
tests/config-flags.pm
install-binPROGRAMS
make
uninstall-binPROGRAMS
clean-binPROGRAMS
installcheck-binPROGRAMS
src/ar.o
src/arscan.o
src/commands.o
src/default.o
src/dir.o
src/expand.o
src/file.o
src/function.o
src/getopt.o
src/getopt1.o
src/guile.o
src/hash.o
src/implicit.o
src/job.o
src/load.o
src/loadapi.o
src/main.o
src/misc.o
src/output.o
src/read.o
src/remake.o
src/rule.o
src/shuffle.o
src/signame.o
src/strcache.o
src/variable.o
src/version.o
src/vpath.o
src/warning.o
src/config.h
src/w32/.dirstamp
src/w32/.deps/.dirstamp
src/w32/compat/posixfcn.o
src/w32/compat/.deps/.dirstamp
src/w32/subproc/misc.o
src/posixos.o
src/remote-cstms.o
src/vms_exit.o
src/vms_export_symbol.o
src/vms_progname.o
src/vmsfunctions.o
src/vmsify.o
src/.dirstamp
src/.deps/.dirstamp
src/w32/pathstuff.o
src/w32/w32os.o
src/w32/compat/dirent.o
src/w32/compat/.dirstamp
src/w32/subproc/sub_proc.o
src/w32/subproc/w32err.o
src/w32/subproc/.dirstamp
src/w32/subproc/.deps/.dirstamp
src/remote-stub.o
mostlyclean-compile
distclean-compile
src/.deps/ar.Po
/usr/include/stdc-predef.h
../src/makeint.h
/usr/lib/gcc/x86_64-linux-gnu/11/include/stdbool.h
../src/../src/mkcustom.h
lib/alloca.h
/usr/lib/gcc/x86_64-linux-gnu/11/include/stddef.h
../src/gnumake.h
/usr/include/x86_64-linux-gnu/sys/types.h
/usr/include/features.h
/usr/include/features-time64.h
/usr/include/x86_64-linux-gnu/bits/wordsize.h
/usr/include/x86_64-linux-gnu/bits/timesize.h
/usr/include/x86_64-linux-gnu/sys/cdefs.h
/usr/include/x86_64-linux-gnu/bits/long-double.h
/usr/include/x86_64-linux-gnu/gnu/stubs.h
/usr/include/x86_64-linux-gnu/gnu/stubs-64.h
/usr/include/x86_64-linux-gnu/bits/types.h
/usr/include/x86_64-linux-gnu/bits/typesizes.h
/usr/include/x86_64-linux-gnu/bits/time64.h
/usr/include/x86_64-linux-gnu/bits/types/clock_t.h
/usr/include/x86_64-linux-gnu/bits/types/clockid_t.h
/usr/include/x86_64-linux-gnu/bits/types/time_t.h
/usr/include/x86_64-linux-gnu/bits/types/timer_t.h
/usr/include/x86_64-linux-gnu/bits/stdint-intn.h
/usr/include/endian.h
/usr/include/x86_64-linux-gnu/bits/endian.h
/usr/include/x86_64-linux-gnu/bits/endianness.h
/usr/include/x86_64-linux-gnu/bits/byteswap.h
/usr/include/x86_64-linux-gnu/bits/uintn-identity.h
/usr/include/x86_64-linux-gnu/sys/select.h
/usr/include/x86_64-linux-gnu/bits/select.h
/usr/include/x86_64-linux-gnu/bits/types/sigset_t.h
/usr/include/x86_64-linux-gnu/bits/types/__sigset_t.h
/usr/include/x86_64-linux-gnu/bits/types/struct_timeval.h
/usr/include/x86_64-linux-gnu/bits/types/struct_timespec.h
/usr/include/x86_64-linux-gnu/bits/pthreadtypes.h
/usr/include/x86_64-linux-gnu/bits/thread-shared-types.h
/usr/include/x86_64-linux-gnu/bits/pthreadtypes-arch.h
/usr/include/x86_64-linux-gnu/bits/atomic_wide_counter.h
/usr/include/x86_64-linux-gnu/bits/struct_mutex.h
/usr/include/x86_64-linux-gnu/bits/struct_rwlock.h
/usr/include/x86_64-linux-gnu/sys/stat.h
/usr/include/x86_64-linux-gnu/bits/stat.h
/usr/include/x86_64-linux-gnu/bits/struct_stat.h
/usr/include/x86_64-linux-gnu/bits/statx.h
/usr/include/linux/stat.h
/usr/include/linux/types.h
/usr/include/x86_64-linux-gnu/asm/types.h
/usr/include/asm-generic/types.h
/usr/include/asm-generic/int-ll64.h
/usr/include/x86_64-linux-gnu/asm/bitsperlong.h
/usr/include/asm-generic/bitsperlong.h
/usr/include/linux/posix_types.h
/usr/include/linux/stddef.h
/usr/include/x86_64-linux-gnu/asm/posix_types.h
/usr/include/x86_64-linux-gnu/asm/posix_types_64.h

[bug #65438] Sort print-targets output.

[Dmitry Goncharov]

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

 Summary: Sort print-targets output.
   Group: make
   Submitter: dgoncharov
   Submitted: Sat 09 Mar 2024 03:34:40 AM 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 Mar 2024 03:34:40 AM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

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

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

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

[Dmitry Goncharov]

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

test3 is not very useful, though, because '/hello/' will match both 'hello'
and 'export hello'.


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

Additional Item Attachment, bug#65360 (group make):

File name: sv65360_fix3.diff  Size:1 KB


File name: sv65360_test3.diff Size:3 KB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-fd9b348a8fcb146b565f753e2f7db1ab857a7bf6.tar.gz


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

An alternative to fix2 can be printing "export" when a variable is exported
regardless of the defaults, even for MAKEFLAGS, etc.
So, here is patch 3 that does that.


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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


> As for export, would it be better to use the make syntax for this

Sure.
i attached sv65360_fix2.diff and sv65360_test2.diff.
The output is make syntax


$ cat makefile
hello=world
all:;
$ ~/src/gmake/make//l64//make -r -p |grep -B1 hello
# makefile (from 'makefile', line 1)
unexport hello = world



> I'm not a fan of adding the "do not export" to comments for non-exported
variables.  Non-exporting is the default and so we should just not say
anything for non-exported variables.

There are variables which are exported by default, MAKEFLAGS, MAKE_TERMOUT,
MAKE_TERMERR, and the variables inherited from env.
When should make print "export" for these?
If make prints "export" for these variable when these variables are exported,
that'd be the opposite of what make does for regular make variables.
PATH and SHELL are even worse, because these variables are exported by default
on certain operating systems only.

For now, this attached patch sv65360_fix2.diff prints either "export" or
"unexport" for each variable. Unless there is an approach to deal with these
variables differently.


$ cat makefile
unexport hello
all:;
$ hello=world ~/src/gmake/make//l64//make -r -p |grep -B1 hello
# environment
unexport hello = world




___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

Additional Item Attachment, bug#65360 (group make):

File name: sv65360_fix2.diff  Size:1 KB


File name: sv65360_test2.diff Size:3 KB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-fd9b348a8fcb146b565f753e2f7db1ab857a7bf6.tar.gz


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

Exporting a make variable makes it available for shell in recipes.

Removal of a semicolon allows make to avoid shell. Instead makes calls
posix_spawn or fork and exec.


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

Additional Item Attachment, bug#65360 (group make):

File name: sv65360_fix.diff   Size:1 KB


File name: sv65360_test.diff  Size:4 KB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-fd9b348a8fcb146b565f753e2f7db1ab857a7bf6.tar.gz


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

This patch has -p print export status, special and conditional flags of each
variable.


$ ls
makefile
$ cat makefile 
hello?=one
all:;
$ ~/src/gmake/make/l64/make -rp |grep  -B1 -w MAKEFLAGS
# makefile special export
MAKEFLAGS = pr


Here make prints that MAKEFLAGS is a special variable and it is exported.



$ ~/src/gmake/make/l64/make -rp |grep  -B1 hello
# makefile conditional do not export (from 'makefile', line 1)
hello = one


Here make prints that hello is conditional and is not exported.


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

 Summary: Extend -p output with export status of each
variable.
   Group: make
   Submitter: dgoncharov
   Submitted: Sat 24 Feb 2024 02:42:51 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: Sat 24 Feb 2024 02:42:51 PM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

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

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

[bug #65324] Fix crash in disable_builtins.

[Dmitry Goncharov]

Additional Item Attachment, bug#65324 (group make):

File name: sv65324.diff   Size:1 KB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-f5e892eb0bd66f106ebc508b2a1f40d7763ca3f9.tar.gz


___

Reply to this item at:

  

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

[bug #65324] Fix crash in disable_builtins.

[Dmitry Goncharov]

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

Make crashes when -r and MAKEFLAGS= are specified on the command line.

On startup make begins to process command line arguments. During processing of
"MAKEFLAGS=" make calls reset_makeflags, which in turn calls disable_builtins,
which dereferences null suffix_file.



$ ls
makefile
$ cat makefile 
all:;
$ ~/src/gmake/make/m64/make -r MAKEFLAGS=
../src/main.c:3476:13: runtime error: member access within null pointer of
type 'struct file'
AddressSanitizer:DEADLYSIGNAL
=
==15066==ERROR: AddressSanitizer: SEGV on unknown address 0x0088 (pc
0x560ed1b164e0 bp 0x7ffd870f7ee0 sp 0x7ffd870f7ed0 T0)
==15066==The signal is caused by a READ memory access.
==15066==Hint: address points to the zero page.
#0 0x560ed1b164e0 in disable_builtins ../src/main.c:3476
#1 0x560ed1b10e95 in reset_makeflags ../src/main.c:3098
#2 0x560ed1b712a9 in set_special_var ../src/variable.c:1325
#3 0x560ed1b72e89 in do_variable_definition ../src/variable.c:1693
#4 0x560ed1b746a7 in try_variable_definition ../src/variable.c:1889
#5 0x560ed1b103df in handle_non_switch_argument ../src/main.c:3015
#6 0x560ed1b110c7 in decode_switches ../src/main.c:3144
#7 0x560ed1b052ef in main ../src/main.c:1615
#8 0x7f1abca29d8f in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
#9 0x7f1abca29e3f in __libc_start_main_impl ../csu/libc-start.c:392
#10 0x560ed1a94654 in _start
(/home/dgoncharov/src/gmake/make/m64/make+0x14c654)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ../src/main.c:3476 in disable_builtins
==15066==ABORTING
Aborted (core dumped)
$


This is a recent regression. Before a382ac6cd17eedf535407d29bcfc3cef04bbc3bc
this was not an issue, because MAKEFLAGS was not marked as special.


___

Reply to this item at:

  

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

[bug #65324] Fix crash in disable_builtins.

[Dmitry Goncharov]

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

 Summary: Fix crash in disable_builtins.
   Group: make
   Submitter: dgoncharov
   Submitted: Sat 17 Feb 2024 04:27:47 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: Sat 17 Feb 2024 04:27:47 AM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

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

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

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

[Dmitry Goncharov]

Additional Item Attachment, bug#65323 (group make):

File name: sv65323.diff   Size:0 KB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-f5e892eb0bd66f106ebc508b2a1f40d7763ca3f9.tar.gz


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

functions/shell/t022.mk crashes certain shells.
E.g. when ksh is used as /bin/sh.
That's the test with make exporting a variable whos name is 40K characters
long.
I tried using perl as a shell, but perl exits with an error message.
The patch in the attachment runs the test on bash.


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

 Summary: Functions/shell test 22 causes ksh to crash.
   Group: make
   Submitter: dgoncharov
   Submitted: Sat 17 Feb 2024 02:50:44 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: Sat 17 Feb 2024 02:50:44 AM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

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

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

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

[Dmitry Goncharov]

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


> Sorry for the delay in examining this bug.

Thank you for looking at this.

...
> However, I tend to agree with you that this is perhaps too much "inside
baseball" for the default behavior. 

i also think, this is too much to be useful. E.g. in your example should not
.SUFFIXES: also list .h?

> I think you are mostly correct in your determination of the problem with one
exception: when the .SUFFIXES list is cleared explicitly, then we should not
create any dummy pattern rules and thus these match-anything rules SHOULD be
matched.

Well, this bug report (and the attached patch) was only intended to ensure
that when -r is specified, match-anything rule are not eligible for .c, .h,
etc files.

For the reasons presented in comment 3, i like the current behavior, that when
.SUFFIXES is cleared, then match-anything rules are still not eligible for .c,
.h, etc files. i feel, this behavior is more suitable for match-anything
rules. In the end, match-anything rules were created to build binaries which
have no suffixes (like 'cp'), not .c files. Maybe we can update the manual to
say that match-anything rules do not build files with built-in list of known
suffixes, whether .SUFFIXES is cleared or not?



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

Would not that contradict the manual?
E.g. if the makefile contains


.c.o:
$(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<


and -r is specified, then make should take '.c.o' as a target name, rather
than as a suffix rule.
If .SUFFIXES is not cleared, then will make take '.c.o' as a target name or as
a suffix rule?

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

i'd need to see the patch to comment. Do you think you can post the patch?


___

Reply to this item at:

  

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

Re: Behavior change related to MAKEFLAGS and recursive make in version 4.4.1

[Dmitry Goncharov]

On Thu, Jan 25, 2024 at 12:39 PM Ouellette, Paul  wrote:
>
> Hello,
>
> Consider the following makefiles:
> $ cat Makefile
> MAKEFLAGS+=VAR=foo
> all:
> $(info make VAR=$(VAR))
> @echo "env  VAR=$$VAR"
> $(MAKE) -C lib
> $ cat lib/Makefile
> all:
> @echo "env  VAR=$$VAR"
> $(info make VAR=$(VAR))
>


Thank you for your report.
Variable VAR exists in the make database even with the latest make.
However, unlike older make, VAR is not exported.
i added variable "world" to your makefile for comparison.
$ ls
lib  makefile
$ cat makefile
MAKEFLAGS+=VAR=foo
world=one

#export VAR world
all:
$(info parent make VAR=$(VAR), world=$(world))
@echo "parent env  VAR=$$VAR, world=$$world"
$(MAKE) -C lib
$ cat lib/makefile
all:
$(info child make VAR=$(VAR), world=$(world))
@echo "child env  VAR=$$VAR, world=$$world"
$ ~/src/gmake/make//m64//make --no-print-directory -rp |grep 'VAR = '
VAR = foo
$ ~/src/gmake/make//m64//make --no-print-directory -r
parent make VAR=foo, world=one
parent env  VAR=, world=
/home/dgoncharov/src/gmake/make//m64//make -C lib
child make VAR=, world=
child env  VAR=, world=


If we uncomment the export directive

$ cat makefile
MAKEFLAGS+=VAR=foo
world=one

export VAR world
all:
$(info parent make VAR=$(VAR), world=$(world))
@echo "parent env  VAR=$$VAR, world=$$world"
$(MAKE) -C lib
$ ~/src/gmake/make//m64//make --no-print-directory -r
parent make VAR=foo, world=one
parent env  VAR=foo, world=one
/home/dgoncharov/src/gmake/make//m64//make -C lib
child make VAR=foo, world=one
child env  VAR=foo, world=one
$

We can see, VAR and world behave the same here.
We can also see that the older make would export VAR.
MAKEFLAGS is exported by default.
We can see, in older make variables defined in MAKEFLAGS were also
exported by default.
In the latest make variables defined in MAKEFLAGS are not exported by default.
Looks like we should restore exporting variables defined in MAKEFLAGS.


regards, Dmitry

[bug #65211] Fix load and loadapi tests.

[Dmitry Goncharov]

Additional Item Attachment, bug#65211 (group make):

File name: sv65211.diff   Size:1 KB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-d498c7872ab0fd8804784504844dc75b621e1bd9.tar.gz


___

Reply to this item at:

  

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

[bug #65211] Fix load and loadapi tests.

[Dmitry Goncharov]

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

load and loadapi tests fail when compiler complains about unused variables.
E.g.


$ cat work/features/load/t004.diff
*** t004.base   Thu Jan 25 17:30:36 2024
--- t004.logThu Jan 25 17:30:36 2024
***
*** 1,2 
--- 1,10 
  rebuilding testload.so
+ testload.c: In function 'testload_gmk_setup':
+ testload.c:11:34: warning: unused parameter 'abi' [-Wunused-parameter]
+11 | testload_gmk_setup (unsigned int abi, gmk_floc *pos)
+   | ~^~~
+ testload.c: In function 'explicit_setup':
+ testload.c:21:30: warning: unused parameter 'abi' [-Wunused-parameter]
+21 | explicit_setup (unsigned int abi, gmk_floc *pos)
+   | ~^~~
  pre= post=testload.so implicit
$




___

Reply to this item at:

  

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

[bug #65211] Fix load and loadapi tests.

[Dmitry Goncharov]

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

 Summary: Fix load and loadapi tests.
   Group: make
   Submitter: dgoncharov
   Submitted: Thu 25 Jan 2024 10:39:03 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: Thu 25 Jan 2024 10:39:03 PM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

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

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

Re: New conditional assignment facility

[Dmitry Goncharov]

On Mon, Jan 22, 2024 at 8:16 AM Paul Smith  wrote:
> I don't understand the point you are making about +!=.

If all new operators behave the same as +=, when the variable exists, then
+!= is not needed, because +!= would do the same as +=$(shell ...).

Based on your explanations, it looks like you want the new operators
to differ from +=, when the variable exists.
Which brings me to the conclusion that this is not only about having
+:= create a simple variable, when there is no variable.
This project must have some other goals?
In other words, in which scenarios do you envision the new operators to be used?

regards, Dmitry

Re: Segmentation Fault on Exported Resursively Expanded Variable

[Dmitry Goncharov]

On Tue, Jan 16, 2024 at 1:21 PM Henrik Carlqvist  wrote:
>
> On Tue, 16 Jan 2024 06:59:30 +
> MIAOW Miao  wrote:
> > if ((*ep)[nl] == '=' && strncmp (*ep, v->name, nl) == 0)
>
> Looking at that line, the rather obvious fix would be to change it to:
>
> if (strncmp (*ep, v->name, nl) == 0 && (*ep)[nl] == '=')


i bet, the purpose of having (*ep)[nl] == '=' check before strncmp was
to relieve make from running strncmp unless the variables have the
same length.
Similarly, the fix attached to the savannah report
 size_t len = strlen (*ep);
 if (len >= nl && (*ep)[nl] == '=' && memcmp (*ep, v->name, nl) == 0)

does the length check before memcmp for the same purpose, to relieve
make from running memcmp, unless needed.

For every char, strncmp does two checks, n and the character. strlen
does only one check.
Without doing any measurements, i expect, strlen do better than
strncmp when strlen (*ep) is shorter than nl.
On the other hand, when v->name is half the length of *ep, we'd prefer strncmp.

regards, Dmitry

Re: New conditional assignment facility

[Dmitry Goncharov]

On Sun, Jan 21, 2024 at 11:17 AM Paul Smith  wrote:

> I think you wrote that wrong: I think you mean "otherwise +:= behaves
> the same as +="... ?

You are right.

Let us clarify the goal of these enhancements?
i assumed that the goal of these enhancements was to allow code like
hello+:=$(world)
create 'hello' as a simple variable, if 'hello' does not exist yet.

After reading your != example, i realize i misunderstood the meaning
of option one.
Let me correct myself.

If the only goal was to allow +:= create a simple variable, then can
we do the following?
"If no variable with this name exists, then +:= creates a simple
variable, and +:::= creates an immediately-expanded-and-escaped
variable. Otherwise, +:= and +:::= behave the same as +=".
If we go with this, then there is no need for +!=, because +!= would
behave as +=. Similarly, there is no need for +::=, because +::= would
behave as +:=.

regards, Dmitry

Re: New conditional assignment facility

[Dmitry Goncharov]

On Thu, Jan 11, 2024 at 7:55 AM Paul Smith  wrote:
> So the new confusion becomes, what happens if you use "+" to append to
> an existing variable that has a different type?
>
> Due to decades of history (and, to be honest, significant technical
> incentive), we have to say that in this case:
>
> bar = xx
> biz = yy
> FOO := $(bar)
> FOO += $(biz)
> bar = 1
> biz = 2
>
> FOO is a simply-expanded variable and $(biz) is expanded immediately
> even though it uses a "+=" assignment, and FOO is "xx yy".
>
> But then, what do we say about this case:
>
> bar = xx
> biz = yy
> FOO = $(bar)
> FOO +:= $(biz)
> bar = 1
> biz = 2
>
> ? There appear to be two options:
>
> Either we could follow the example of "+=" and say that the assignment
> type in "+:=" only takes effect if the variable doesn't already have a
> type but if it does that type is preserved, so in the above example FOO
> would continue to be recursively expanded in spite of "+:=", so FOO has
> a value of "$(bar) $(biz)" and $(FOO) gives "1 2".
>
> Or we could say that "+=" is a special case where we follow the type of
> the existing variable, but for the other operators we first expand the
> right hand side then append the result regardless of the original type.
> So in the above example FOO is still a recursive variable, BUT $(baz)
> is expanded immediately before appending so the value of FOO would be
> "$(bar) yy" and $(FOO) gives "1 yy".
>
> Neither of these is great, in that they both will cause people to be
> surprised, in different situations.

i like option one. It is simple to explain in the manual and, as far
as i can tell, option one does what users want.
As long as the manual says something like "when there is no variable
+:= creates a simple variable, otherwise +:= behaves the same as :="
is there still room for surprises?

i suspect option two is a lot trickier to use in a makefile. Option
two introduces a doubt in the mind of a makefile author. If the
makefile author knows that all the appends +=, :+=, ::+=+, :::+=
follow the variable flavor, once the variable is created, then the
author sees that a variable is recursive at the top of a makefile and
knows anything can be appended to the variable at the bottom of the
makefile and the value will contain that anything at build time. If we
go with option two then the author does not have this knowledge. In
your example, one scenario is that the author misses that the
assignment is +:= and sets biz to 2 and expects that FOO contains "1
2" at build time. Another scenario is that 'FOO +:= $(biz)' is
introduced long after 'biz = 2'. Similarly, if the author wants to
introduce a +:= assignment somewhere in a makefile, they have to check
that the makefile does not contain another assignment later. In our
example, if the author wanted to introduce FOO +:= $(biz) they will
have to check that biz is not assigned later.



regards, Dmitry

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

[Dmitry Goncharov]

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

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


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

Paul, i attached fix2 and test2. fix2 is split into 2 parts to ease review.
Should be applied in order part1 before part2. Thanks for review.


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

Additional Item Attachment, bug#64822 (group make):

File name: sv64822_fix2_part1.diffSize:9 KB


File name: sv64822_test2.diff Size:9 KB


File name: sv64822_fix2_part2.diffSize:7 KB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-9b198ebc9ee3d2ae2d2a70bafdf8252fdef354d3.tar.gz


___

Reply to this item at:

  

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

Re: Segmentation Fault on Exported Resursively Expanded Variable

[Dmitry Goncharov]

On Mon, Jan 15, 2024 at 9:02 AM MIAOW Miao  wrote:
> Here is a Makefile that can reproduce the segmentation fault:
>
> THIS_LONG_VARIABLE_NAME_PREDUCE_THE_ERROR= $(shell echo hello)
> export THIS_LONG_VARIABLE_NAME_PREDUCE_THE_ERROR
>
> all: ; echo "abc"


Thank you for your report.
A added a fix here https://savannah.gnu.org/bugs/index.php?65172.

regards, Dmitry

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

[Dmitry Goncharov]

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

A user reported a buffer overflow on a variable with a long name.


Here is a fix.

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

* src/expand.c (recursively_expand_for_file): Fix a buffer overrun.
* tests/scripts/functions/shell: Add a test.

diff --git a/src/expand.c b/src/expand.c
index fe09c9c3..283a3d47 100644
--- a/src/expand.c
+++ b/src/expand.c
@@ -164,9 +164,11 @@ recursively_expand_for_file (struct variable *v, struct
file *file)
   /* We could create a hash for the original environment for speed, but
a
  reasonably written makefile shouldn't hit this situation...  */
   for (ep = environ; *ep != 0; ++ep)
-if ((*ep)[nl] == '=' && strncmp (*ep, v->name, nl) == 0)
-  return xstrdup ((*ep) + nl + 1);
-
+{
+  size_t len = strlen (*ep);
+  if (len >= nl && (*ep)[nl] == '=' && memcmp (*ep, v->name, nl) ==
0)
+return xstrdup ((*ep) + nl + 1);
+}
   /* If there's nothing in the parent environment, use the empty string.
  This isn't quite correct since the variable should not exist at
all,
  but getting that to work would be involved. */




Here is a test.

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

* src/expand.c (recursively_expand_for_file): Fix a buffer overrun.
* tests/scripts/functions/shell: Add a test.

diff --git a/tests/scripts/functions/shell b/tests/scripts/functions/shell
index e5c346cc..b9b9ee32 100644
--- a/tests/scripts/functions/shell
+++ b/tests/scripts/functions/shell
@@ -213,4 +213,15 @@ endif
   '--no-print-directory -j2', ": 2\n: 1");
 }

+if ($port_type eq 'UNIX') {
+# sv 65172.
+# Buffer overrun in recursively_expand_for_file on a variable with a
long
+# name.
+my $v = "a1234567890" x 4 x 1000;
+run_make_test("
+export $v=\$(shell echo hello)
+all:; \@echo \$\$$v
+", '', "hello\n");
+}
+
 1;



The original mail is here
https://lists.gnu.org/archive/html/bug-make/2024-01/msg00044.html


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

 Summary: Fix a buffer overrun on a variable with a long name.
   Group: make
   Submitter: dgoncharov
   Submitted: Tue 16 Jan 2024 10:43:18 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: Tue 16 Jan 2024 10:43:18 PM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

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

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

Re: Segmentation Fault on Exported Resursively Expanded Variable

[Dmitry Goncharov]

On Mon, Jan 15, 2024 at 9:02 AM MIAOW Miao  wrote:
> Here is a Makefile that can reproduce the segmentation fault:
>
> THIS_LONG_VARIABLE_NAME_PREDUCE_THE_ERROR= $(shell echo hello)
> export THIS_LONG_VARIABLE_NAME_PREDUCE_THE_ERROR
>
> all: ; echo "abc"
>
> Commands log:
>
> user@fedora:~$ make
> echo "abc"
> Segmentation fault (core dumped)


Does not reproduce for me with make from master.

regards, Dmitry

Re: Handling of MAKEFLAGS

[Dmitry Goncharov]

On Wed, Jan 10, 2024 at 5:46 PM Paul Smith  wrote:
>
> On Wed, 2024-01-10 at 17:20 -0500, Dmitry Goncharov wrote:
>
> Investigating why I discovered the issue was as I mentioned below; once
> we have set the flag for -e (the env_overrides global variable) there's
> no way to unset it.

> What I was thinking was that the handling of MAKEFLAGS would be changed
> so that the content of the MAKEFLAGS variable would be considered the
> source of truth, and the values of the global variables set by the
> command_switch array etc. would only be convenient shortcuts for that
> information.
>
> In particular, every time MAKEFLAGS is changed we would first _reset_
> all the global variables back to their default values effectively
> undoing whatever settings were made by the previous value of MAKEFLAGS,
> then we would re-parse MAKEFLAGS from scratch and set whatever values
> were there.
>
> By doing this we would ensure that, for example, if you have:
>
>MAKEFLAGS += -e
>
>MAKEFLAGS := $(subst e,,$(word 1,$(MAKEFLAGS))) \
>   $(wordlist 2,$(words $(MAKEFLAGS),$(MAKEFLAGS))
>
> then after the first MAKEFLAGS assignment we'd reset the global option
> variables to their default (env_override = 0), then parse MAKEFLAGS
> which sets env_override = 1.
> Then after the second MAKEFLAGS assignment we'd reset the global option
> variables to their default so env_override = 0, then after we parse
> MAKEFLAGS the "e" option is not set anymore and env_override is left 0.

You are designing a new feature, aren't you? Specifically, the ability
to unset -e.
If really needed, a makefile can reset -e on the command line for
submake and have submake do the work.
Alternatively, it is possible to introduce the opposite switch, just
like -S and -k.


> After all that, we can go through the variables and reset the override
> status o_override vs. o_env_override if the value changed.  Or, maybe
> there's a better way to handle that; maybe for example we should
> consider chaining variable sets like we do for target-specific
> variables and inheritance, and keeping environment variables in a
> different set and swapping the order of "env" vs "make" variable sets.
> But this might be complicated, there are some special cases for
> handling the global set.

i agree that the makeflags business is overly complex. i feel, the
main issue is that makeflags serves two functions, it carries command
line switches to submake and it allows a makefile to set switches.
This ability to set switches is the cause of the complexity.
Instead of
MAKEFLAGS+=-R

i'd rather introduce a function like
$(toggle_switch R, 1) # Set -R.
$(toggle_switch R, 0) # Reset -R.

However, this ship sailed 30 years ago.


> Since I actually consider -e to be a terrible feature and would never
> consider using it myself, maybe it's better to do the stupid, simple
> thing and just go through all the variables and reset them :)

i like this better, as long as the behavior matches the manual.

regards, Dmitry

Re: Handling of MAKEFLAGS

[Dmitry Goncharov]

On Tue, Jan 9, 2024 at 5:35 PM Paul Smith  wrote:
> Hi Dmitry;

Good morning, Paul.



> As an example, for the -e change I experimented with simply going
> through the variable database and switching the origin from o_env to
> o_env_override or vice versa.

Do you mean an alternative fix for https://savannah.gnu.org/bugs/?64803?
Do i understand your idea correctly that you want to import all env
variables as usual with origin o_env and then decode switches and then
look if -e was specified and then go through the db and replace o_env
with o_env_override?


>
> This works great EXCEPT that if we disable the -e option via MAKEFLAGS,
> it doesn't actually change the global setting back again; a switch only
> "enables" but the _lack_ of a switch never "disables".

right.

>
> In order to make this work we'd need to have a way to reset the global
> settings to their default values.

Here, i lost track. What do you mean by "this"? Do you mean replacing
o_env with o_env_override?

> Does this make sense?

The idea to update the db makes sense to me.

regards, Dmitry

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

[Dmitry Goncharov]

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

Paul, please do not apply the attached patch. I prepared a more extensive test
and another patch, to cover more cases. Going to attach the new patch in a few
days.


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

Rob, that's right. The patch fixes both. In fact, this bug report is a
duplicate of https://savannah.gnu.org/bugs/?36486.


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

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


___

Reply to this item at:

  

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

Re: Surprising pattern matching and .EXTRA_PREREQS behaviours

[Dmitry Goncharov]

On Mon, Nov 20, 2023 at 8:37 AM Daniel Gerber  wrote:

> 1. Second expansion is not applied to .EXTRA_PREREQS

Thanks for your report. You can find a patch here
https://savannah.gnu.org/bugs/index.php?65006.


> 2. Setting .EXTRA_PREREQS as pattern-specific variable is not supported

A couple of years ago i implemented pattern-specific .EXTRA_PREREQS.
The impl is here
https://github.com/dgoncharov/make/tree/pattern_specific_extra_prereqs.
i wanted a more efficient impl and this impl is still not merged.


> 1. How to add a prerequisite to all targets matching some pattern - in
particular, their parent directory?


.SECONDEXPANSION:
%.ext:| $$(@D)/;
%/:; mkdir -p $@


Another option

obj/%.ext:| obj;
obj/:; mkdir -p obj


> 2. How to set a variable for all targets matching /prefix_?

dirs/prefix_%: hello=world

regards, Dmitry

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

[Dmitry Goncharov]

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

The patch in the attachment implements second expansion of the value of
.EXTRA_PREREQS, along with a test.
The origin report is here
https://lists.gnu.org/archive/html/bug-make/2023-11/msg00018.html.


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

Additional Item Attachment, bug#65006 (group make):

File name: sv65006.fixSize:2 KB


File name: sv65006.test   Size:1 KB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-a4985939236408f0d28bc98ad54d41078445f540.tar.gz


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

 Summary: Implement second expansion of .EXTRA_PREREQS.
   Group: make
   Submitter: dgoncharov
   Submitted: Sun 10 Dec 2023 12:44:15 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: Sun 10 Dec 2023 12:44:15 AM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

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

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

Re: Bug with $(info xxx) in 4.2.1

[Dmitry Goncharov]

On Tue, Dec 5, 2023 at 12:01 AM Aaron Williams  wrote:

> What is happening is I will get the error:
> *** recipe commences before first target.  Stop.
> At the line with $(info xxx) unless I do not precede it with a tab.

This error is expected. A tab precedes a recipe.
It does not matter what the recipe contains info or no info. It is
still a recipe and should be preceded by a rule definition.

regards, Dmitry

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

[Dmitry Goncharov]

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

The rules in this example 'foo%: foo%.txt' and 'foo%.txt: foo%.sh' are
implicit. Implicit rules can be specified in the makefile. Make's behavior is
correct.


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

Order-only beats phony.
If a target depends on an order-only prerequisite, then this prerequisite does
not cause the target to be updated, whether this prerequisite is phony or
not.

> i guess only issue might be, "should .PHONY: give an error for order-only
pre-requisites?".  i can't think of a reason such a pre-requisite would make
any sense

It indeed useless to mark a prerequisite of .PHONY as order-only, given that
make never builds target .PHONY.

However, a prerequisite of a proper target can be marked both phony and
order-only and there are makefiles which do that.




___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

The described behavior is expected and has nothing to do with order-only.
The manual contains the following


The implicit rule search (see Using Implicit Rules) is skipped for .PHONY
targets.


You need an explicit rule for file.elc.


___

Reply to this item at:

  

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

Re: [bug #64571] Add option to print targets

[Dmitry Goncharov]

On Wed, Nov 1, 2023 at 10:26 AM Tim Murphy  wrote:
> Perhaps make could do with some sort of plugin mechanism?  I know it has the 
> load keyword within makefiles but I'm not sure if functions have access to 
> enough global state to e.g. print out a list of targets.

Currently there is no interface for loadable shared objects to access
make's database. However, such an interface can be added. Such an
interface can provide a greater flexibility than a command line make
switch. With such an interface a plugin can implement
print_phony_targets or print_all_targets or
print_targets_that_match_a_pattern or whatever you want. Also, you
could call your function anywhere in the makefile, e.g.

load printdb.so
$(printdb)
include common.mk
$(printdb)

The price of this flexibility is that each user who needs this will
have to implement and maintain their printdb.so.

>  One might want other entry points like "after parsing" or "before reading a 
> makefiule" or "after updating a target" where one's plugin functions might be 
> called.

There is no such thing as "entry points" here. The load directive is
called at parse time. After that makefile can call the functions that
the shared object provides. You can call your function before or after
updating a target.

i personally, use -p and so far see no need to duplicate the function
of -p in a new switch.
Is there anything that this new switch would provide that -p cannot provide?

regards, Dmitry

Re: Possible bug with pattern-specific variables

[Dmitry Goncharov]

On Wed, Sep 27, 2023 at 9:33 AM Markus F.X.J. Oberhumer
 wrote:

> Very stange GNU make behaviour with pattern-specific variables - note

Thank you for your report.
i attached a fix here https://savannah.gnu.org/bugs/index.php?64822

regards, Dmitry

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

[Dmitry Goncharov]

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

File name: sv64822_test.diff  Size:9 KB


File name: sv64822_fix.diff   Size:3 KB




___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

Markus Oberhumer reported a bug.

Appending to a pattern specific variable produces an incorrect value in the
presence of a command line definition or an env override of the variable.



$ ls
makefile
$ cat makefile
al%: hello+=pattern
all:; $(info hello=$(hello))
$ # this is the lastest make from master
$ ~/src/make/m64/make hello=cmd
hello=cmd cmd
make: 'all' is up to date.
$


The following takes place.
1. At parse time record_target_var sets the value of a pattern specific
variable to the value defined on command line or to the value of the env
override.
2. Later, at build time, recursively_expand_for_file appends this value of
the
variable (set in record_target_var) to the command line value again,
regardless
of the origin of the variable.


This patch modifies recursively_expand_for_file to avoid appending, unless
the
origin of the variable beats or equals the origin of one of the parent
definitions of this variable.

Even though this bug and fix are not related to sv 64803, the test attached
here tests (among other things) appending in the presence of an env override.
That test requires the fix from sv 64803 to pass.

The original bug report is here
https://lists.gnu.org/archive/html/bug-make/2023-09/msg00015.html. 



___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

 Summary: Fix appending to a pattern specific variable.
   Group: make
   Submitter: dgoncharov
   Submitted: Fri 27 Oct 2023 12:50:37 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: Fri 27 Oct 2023 12:50:37 AM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

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

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

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

[Dmitry Goncharov]

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

File name: sv64803_fix_part1.diff Size:3 KB


File name: sv64803_fix_part2.diff Size:14 KB




___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

Variables inherited from env have incorrect origin 'environment' when -e is
set
and the makefile does not modify the variable.



$ ls
makefile
$ cat makefile
$(info at parse time hello=$(hello), origin = $(origin hello))
all:; $(info at build time hello=$(hello), origin = $(origin hello))
$ # this is the latest make from master
$ hello=world ~/src/make/m64/make -e
at parse time hello=world, origin = environment
at build time hello=world, origin = environment
make: 'all' is up to date.
$ hello=world make-4.3 -e
at parse time hello=world, origin = environment
at build time hello=world, origin = environment
make-4.3: 'all' is up to date.



This happens because make goes through env variables and defines related make
variables
before the command line switches are processed and make has not figured out
yet that
-e is specified.
This patch reads command line switches and sets global variable
'env_overrides' before 
going through env variables.

This fix is split into 2 patches. The patches are supposed to be applied in
order, part1 before part2. This split keeps logically independent
changes in separate commits. Hopefully, this will make review easier and
allows
to refer to or revert individual commits.




___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

 Summary: Fix origin of variables from env when -e is set.
   Group: make
   Submitter: dgoncharov
   Submitted: Sat 21 Oct 2023 09:19:42 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 21 Oct 2023 09:19:42 PM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

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

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

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

[Dmitry Goncharov]

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

VAR_1 is a recursively expanded variable. When make defines this
variable, the value is set to string '$(shell echo 1)'. No subshell is
spawned at this time. Each time make expands this variable, make
spawns a shell and has the shell execute 'echo 1' and the output of
the subshell is the result of the expansion.

This is in contrast with
VAR_X := $(shell echo 1)

VAR_X is a simply expanded variable. When make defines this variable,
make spawns a shell and has the shell execute 'echo 1' and sets the
value of the variable to the output of the subshell. Then each time
this variable is expanded, make won't spawn the shell again.

The difference is critical in this scenario. With variables exported
to subshell, each time make spawns a subshell, it has to expand all
these variables. E.g. in order to expand VAR_7, make has to spawn a
subshell. In order to spawn this subshell, make has to export VAR_6,
VAR_5, etc. Each of those requires its own subshell, which again
requires make to export these variables, etc.

Prefer simply expanded variables with $(shell).


Given that sush questions keep arising, maybe we should update NEWS with a
warning about recursively expanded variables in combination with $(shell).


___

Reply to this item at:

  

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

Re: Exponential Runtime in make 4.4.1 when export is used

[Dmitry Goncharov]

On Wed, Oct 4, 2023 at 6:09 PM Till Backhaus  wrote:
> This rather short Makefile shows exponential runtime depending on the number 
> of variables.
> VAR_1 ?= $(shell echo 1)
...

VAR_1 is a recursively expanded variable. When make defines this
variable, the value is set to string '$(shell echo 1)'. No subshell is
spawned at this time. Each time make expands this variable, make
spawns a shell and has the shell execute 'echo 1' and the output of
the subshell is the result of the expansion.

This is in contrast with
VAR_X := $(shell echo 1)

VAR_X is a simply expanded variable. When make defines this variable,
make spawns a shell and has the shell execute 'echo 1' and sets the
value of the variable to the output of the subshell. Then each time
this variable is expanded, make won't spawn the shell again.

The difference is critical in this scenario. With variables exported
to subshell, each time make spawns a subshell, it has to expand all
these variables. E.g. in order to expand VAR_7, make has to spawn a
subshell. In order to spawn this subshell, make has to export VAR_6,
VAR_5, etc. Each of those requires its own subshell, which again
requires make to export these variables, etc.

Prefer simply expanded variables with $(shell).

regards, Dmitry

Re: Static pattern rules with more than one '%'

[Dmitry Goncharov]

On Tuesday, August 29, 2023, Alejandro Colomar  wrote:

> Hi Paul,
>
> On 2023-08-29 14:45, Paul Smith wrote:
> > On Tue, 2023-08-29 at 11:32 +0200, Alejandro Colomar wrote:
> >> Am I missing something?  Is something like that allowed anyhow?
> >
> > Multiple "%" are allowed, in that they won't throw an error.  But, only
> > the first "%" is replaced.  The second (and subsequent) "%" are just
> > normal characters, not pattern matching.
>
> Thanks!  That was my expectation before reading the docs.  Maybe you
> could reword it to be explicit that only one % is used as a wildcard.


Good morning.

The same paragraph says that after matching % the rest of the name must
match exactly.
However, be careful if you want to rely on this. We fixed it just recently.
4.3 and earlier would replace all %,

Regards, Dmitry




> Cheers,
> Alex
>
> --
> 
> GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
>
>

Re: MAKEFLAGS=-r

[Dmitry Goncharov]

On Wed, Jul 19, 2023 at 4:36 PM Jeffrey Walton  wrote:
> SUFFIXES does not seem to work too well. 'make -d' still shows all the
> extra noise. For example, I added to the top of my GNUmakefile:
>
>.SUFFIXES: .h .c .cpp .S .o
>
> I still see:
>
> $ make -d -f GNUmakefile
...
>   Trying implicit prerequisite 'GNUmakefile.o'.

If you want to reset the list of known suffixes
.SUFFIXES:
You can then add your own suffixes to this list
.SUFFIXES: .h .c .cpp .S .o

If you want to prevent make from remaking GNUmakefile
GNUmakefile::;

regards, Dmitry

Re: MAKEFLAGS=-r

[Dmitry Goncharov]

On Mon, Jul 17, 2023 at 5:45 AM Bruno Haible  wrote:
> And finally, MAKEFLAGS is not even mentioned in the main index of the GNU Make
> documentation [5], and only regarding "recursion" in the Variables index [6].

5.7.3 contains

"The MAKEFLAGS variable can also be useful if you want to have certain
options, such as ‘-k’ (see Summary of Options), set each time you run
make. You simply put a value for MAKEFLAGS in your environment. You
can also set MAKEFLAGS in a makefile, to specify additional flags that
should also be in effect for that makefile. "

regards, Dmitry

Re: MAKEFLAGS=-r

[Dmitry Goncharov]

On Mon, Jul 17, 2023 at 10:47 AM David Boyce  wrote:
>
> Everything else aside, there's a profound difference between MAKEFLAGS=-r and 
> MAKEFLAGS+=-r. The latter is far less destabilizing.
In a relatively fresh make (make-4.0 or later) setting MAKEFLAGS=-r in
the makefile takes effect and other options specified on the command
line also take effect.

regards, Dmitry

Re: disabling the built-in rules

[Dmitry Goncharov]

On Mon, Jul 17, 2023 at 2:41 PM Alejandro Colomar
 wrote:

> MAKEFLAGS += --no-builtin-variables

If your makefiles are supposed to work on systems other than linux
(still with gnu make), then you may need built-in variables.
These variables contain different values on different systems.
e.g. ARFLAGS has value '-rv' on linux and value '-Xany -rv' on aix.

regards, Dmitry

Re: MAKEFLAGS=-r

[Dmitry Goncharov]

On Mon, Jul 17, 2023 at 5:45 AM Bruno Haible  wrote:
> So I wondered whether I should add this variable definition in the Makefile.am
files of my GNU packages.

i think, that would be good.

>   "you should be sure not to include any options that will drastically
>affect the actions of make"

We should ensure that the makefile does not need built-in rules.

>   "It’s best to use GNUMAKEFLAGS only with flags which won’t materially
>change the behavior of your makefiles."

i don't see a reason for gnumakeflags to be suitable for some options,
but not others.
If you set gnumakeflags to some value, that value will be passed to
submake in makeflags, anyway.

> and this on stackoverflow [3]:

>   "You shouldn't set MAKEFLAGS at all. ...
>MAKEFLAGS is intended, really, to be an internal implementation passing
>arguments from a parent make to a child make. It's not intended,
>generally, to be modified by a makefile."

i sort of agree, that was the original purpose.
Then people wanted to be able to have makefile set options.
And someone decided to use makeflags for this as well.
And implemented it.

> and this in Oracle's documentation [4]:
>
>   "Do not define MAKEFLAGS in your makefiles."

i only mean this for gnu make.
If you need your makefiles to be suitable to other makes, then you'll
need to check what other makes do.


> Also, what the example did not tell me: If a Makefile uses MAKEFLAGS=-r and
> the Makefile in a subdirectory needs built-in rules, will the MAKEFLAGS=-r
> setting propagate to the subdirectory?

It will.

You can reset .suffixes instead if you don't want to propagate -r to submake.
Alternatively, you can do something like

oldmflags := $(filter-out -%,$(MAKEFLAGS))
MAKEFLAGS += -r
mflags = MAKEFLAGS="$(oldmflags) $(filter -%,$(MAKEFLAGS)) $(MAKEOVERRIDES)"
all:; $(mflags) $(MAKE) -C lib

regards, Dmitry

Re: wildcard and globstar (was: GNU make troubleshooting)

[Dmitry Goncharov]

On Sun, Jul 16, 2023 at 4:59 PM Alejandro Colomar  wrote:
> I'm still interested in globstar support, though.  It would make that
> line shorter and more robust.  Maybe you could add an option
> --glob=globstar or similar to enable support.


gmake does not keep its own impl of glob. It uses a copy from gnulib
or links against one from glibc.
Such a feature will require a gnulib or glibc maintainer to review.

regards, Dmitry

Re: wildcard and globstar (was: GNU make troubleshooting)

[Dmitry Goncharov]

On Sun, Jul 16, 2023 at 10:49 AM Alejandro Colomar  wrote:
> I guess I'd need some kind of globstar support in GNU Make to be able
> to use that

Do you mean you need to find .mk files in subdirectories at different
depth levels?
mk:=$(wildcard */*/*.mk */*.mk *.mk)

regards, Dmitry

Re: GNU make troubleshooting

[Dmitry Goncharov]

Como estas, Alex?

On Sun, Jul 16, 2023 at 9:59 AM Alejandro Colomar  wrote:
> I applied the following patch

> 

Glad you liked it.
Rather than `find -type f...` (which is painfully slow) why don't you
do something like
mk:=$(wildcard $(MAKEFILEDIR)/*.mk)
?

regards, Dmitry

Re: GNU make troubleshooting

[Dmitry Goncharov]

On Sat, Jul 15, 2023 at 5:27 PM Bruno Haible  wrote:
> I believe these two user goals are so different; they belong in different
> chapters.
i believe, a good approach to big debug output is to modify the
makefile to relieve make from doing redundant work.
Once make only does necessary minimal work only, the debug output is
also necessary and minimal.
In other words, i don't see a chapter on how to avoid big debug output
without optimizing the makefile.


> I believe that 80%-90% of the developers, when they see
> 1000 lines of debug/trace output, give up understanding it after 5 seconds
> and try alternative approaches. (This is based on observing the habits
> of my developer colleagues at work.)

i agree.


> > > Can the addition of 'makefile::;' be replaced by a make option or
> > > by some (sed-based?) postprocessing?
> >
> > There is no option.
> > You can grep away most of the matching lines with 'grep -v makefile'.
>
> Then it's useful to present this as a filter in the troubleshooting
> section.

i'd rather have the manual to teach how to modify the makefile to
relieve make from doing redundant work.
i am puzzled why you prefer working around with options and filters.
Are you thinking about a scenario where you cannot modify the makefile?
Another approach for the case when you cannot modify the makefile is this

$ cat makefile
all: hello
$ make -nd |wc
   13347530   63382
$ make -E $'.DEFAULT_GOAL:=all\nmakefile::;' -nd |wc
7324117   32947

regards, Dmitry

Re: GNU make troubleshooting

[Dmitry Goncharov]

> 1) The title, and what does the user want?
i guess, users want make to do the minimal amount of work required to
fulfil its duties correctly (e.g. track all dependencies, rebuilds,
etc).
This patch is not a full-fledged troubleshooting guide.
This patch describes how to minimize the work that make does and thus
reduce the amount of debug output.
But surely we can change the title.
How about "How to relieve make from redundant work and reduce the
amount of debug output."?

> "Understanding a Makefile's action w.r.t. a given file system state"),
> I do *not* want the state to be modified.
>
> Therefore, how about changing the example to use "make -n -d" instead of
> "make -d" ?
...
> This way, it's reproducible.

Sure.


> Hey, you are modifying the Makefile in order to analyze how it works!
Rather i am presenting different makefiles in order to demonstrate
these techniques that the patch describes.

The techniques that this patch describes
makefile::;
hello.d:;
MAKEFLAGS=-r
are all intended to relieve make from doing redundant work. This helps
performance.
The simplicity of debug output comes as the result of avoiding the work.


My opinion is that, large amounts of debug output is not the problem.
This output is simply make telling us what it does.
My opinion is that, the redundant work itself is the problem.
Once we relieve make from doing this work, the messages go away.
So, when the the number of debug lines changes from 1300 to 47 it is
really make doing that fraction of work.

> Is that really what I want to do and should do, as a user?
i believe, makefile authors should apply these techniques.

> Regarding -r, I would prefer to get told to add an option:

The users won't know and sometimes won't be able to modify the
makefile (e.g. make can be run by another program).
Once the makefile author knows the makefile does not need built-in
rules, they should add MAKEFLAGS=-r in the makefile and
this will do a good service to all their users.
The manual should lead by example.


> Can the addition of 'makefile::;' be replaced by a make option or
> by some (sed-based?) postprocessing?

There is no option.
You can grep away most of the matching lines with 'grep -v makefile'.


regards, Dmitry

Re: GNU make troubleshooting

[Dmitry Goncharov]

On Mon, Jul 10, 2023 at 2:32 PM Bruno Haible  wrote:
>I tried -d a couple of times, and it produced a ton of output, that
>was too much for me to make sense of. Probably 10% to 20% of the
>developers in general have trace filtering skills, that is, know how
>to extract the essential information from a heap of output. It's not
>part of my skills.


i added a patch here https://savannah.gnu.org/bugs/index.php?64428
which hopefully clarifies how to extract essential information from
this output.
i'll copy the contents of the patch here, in case there are questions
or suggestions.

regards, Dmitry

Appendix A Debug Output.

This section demonstrates how to simplify make debug output.

Let us consider this very simple makefile.

$ ls
hello.c  makefile
$ cat makefile
all: hello
$ make
cc hello.c   -o hello

This project consists of one .c file, no headers files a one line makefile.

$ make -d |wc
   13387558   63584
$

1338 lines of debug output just for this makefile which compiled one
source file. Of course, with multiple source code files this debug
output increases tremendously. This makes reading make debug output
difficult.

There are simple techniques that we can utilize to simplify this
output and extract useful information out of it.

Let us see what this output contains.

$ make -d |head
GNU Make 4.4.90
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2023 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'...
Updating makefiles
 Considering target file 'makefile'.
$

This copyright header can be eliminated with tail +7.

$ make -d |tail +7 |head
Reading makefiles...
Reading makefile 'makefile'...
Updating makefiles
 Considering target file 'makefile'.
  Looking for an implicit rule for 'makefile'.
   Trying pattern rule '%: %.o' with stem 'makefile'.
   Trying implicit prerequisite 'makefile.o'.
   Not found 'makefile.o'.
   Trying pattern rule '%: %.c' with stem 'makefile'.
   Trying implicit prerequisite 'makefile.c'.
$

Upon startup make looks for a rule to update the makefile. (see How
Makefiles Are Remade). This is what the initial portion of this debug
output is about. If we don’t need your makefile to be remade, we can
instruct make to skip this update process.

$ cat makefile
all: hello
makefile::;
$ make -d |tail +7 |wc
7304101   32848

Note, we added rule

makefile::;

This addition cut the debug output from 1338 to 730 lines.

Let us update this makefile to track dependencies.

$ cat makefile
all: hello
hello: hello.o; $(CC) -o $ $<
hello.o: hello.c hello.d; $(CC) -MMD -MFhello.d -o $ -c $<
hello.d:
include hello.d
makefile::;
$ make -d |tail +7 |wc
   13417572   63293

We can see tracking of dependencies causes additional work and debug
output. We can simplify this output by providing a recipe for the
’hello.d:’ rule.

$ cat makefile
all: hello
hello: hello.o; $(CC) -o $ $<
hello.o: hello.c hello.d; $(CC) -MMD -MFhello.d -o $ -c $<
hello.d:;
include hello.d
makefile::;
$ make -d |tail +7 |wc
7414168   33471

Note, we added a semicolon after hello.d:. This empty recipe causes
make to skip implicit search for a rule to build hello.d. This
relieves make from doing redundant work and simplifies debug output.

Finally, we can disable built-in rules Catalogue of Built-In Rules.

$ cat makefile
MAKEFLAGS:=-r
all: hello
hello: hello.o; $(CC) -o $ $<
hello.o: hello.c hello.d; $(CC) -MMD -MFhello.d -o $ -c $<
hello.d:;
include hello.d
makefile::;
$ make -d |tail +7 |wc
 47 2591931

These 47 lines are the ones that we were looking for.

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

[Dmitry Goncharov]

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

Paul, please use sv64428_2.diff (the other patch has a typo).


___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

File name: sv64428_2.diff Size:5 KB




___

Reply to this item at:

  

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

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

[Dmitry Goncharov]

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

This patch documents how to simplify make debug output.

(file #54928)

___

Additional Item Attachment:

File name: sv64428.diff   Size:5 KB




___

Reply to this item at:

  

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