Re: MAKEFLAGS=-r

[Bruno Haible]

Dmitry Goncharov wrote:
> 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
https://www.gnu.org/software/make/manual/html_node/Options_002fRecursion.html
> 
> "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. "

This kind of documentation structure has room for improvement.

If MAKEFLAGS has one purpose, the communication with sub-make invocations,
it's got to be documented in a section "Communicating Options to a Sub-make".

If MAKEFLAGS has two different purposes, semantically that far away, there
should be two documentation sections, "Communicating Options to a Sub-make"
and "Activating make options by default".

Bruno

Re: MAKEFLAGS=-r

[Bruno Haible]

Dmitry Goncharov wrote:
> > 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.

Ouch. This is usually undesired, since a developer works on one Makefile
at a time.

Together with the other arguments by Paul [1], this means the .SUFFIXES
approach is much much preferable.

Bruno

[1] https://lists.gnu.org/archive/html/bug-make/2023-07/msg00063.html

Re: disabling the built-in rules

[Bruno Haible]

Paul Smith wrote:
> POSIX
> reserves all targets prefixed with "." (that are not already specified
> in the standard) to the implementation.  So it's fine with POSIX to add
> a pseudo target like .NOBUILTINS; no conforming makefile can use that
> target for anything else.

Thanks for explaining!

Re: disabling the built-in rules

[Bruno Haible]

Paul Smith wrote:
> Or, to test:
> 
>   all:
> 
>   .SUFFIXES:
>   %:: %,v
>   %:: RCS/%,v
>   %:: RCS/%
>   %:: s.%
>   %:: SCCS/s.%

Indeed, this works fine with the 'make' on FreeBSD, NetBSD, OpenBSD,
Solaris 10, and AIX.

> If we were to add something it would be a pseudo-target like:
> 
>   .NOBUILTINS:
> 
> or something like that that would just turn off the entire built-in
> database.

Looks fine.

Except possibly that POSIX does not allow this? Then we would need a
pseudo-target the turns off only the non-standardized part of the built-in
database, say, .NO_GNU_BUILTINS. And users would have to write:

  .SUFFIXES:
  .NO_GNU_BUILTINS:

Bruno

Re: disabling the built-in rules

[Bruno Haible]

Paul Smith wrote:
> I do not
> usually recommend this method of clearing the default rules.  There are
> issues with modifying MAKEFLAGS, especially with some older versions of
> GNU Make.  And also, in some older versions setting MAKEFLAGS in the
> makefile doesn't actually take effect anyway: it only helps for sub-
> makes.

Thanks for the clarification.

> My recommendation has been to disable the built-in rules directly, if
> you don't need them.  For example you can use:
> 
>   .SUFFIXES:
> 
> to disable most of the built in rules (this is a POSIX standard
> facility so it's helpful even for other versions of make).

That's nice, because as a developer I don't want to have to test my
Makefiles with GNU make and with non-GNU make separately.

> Unfortunately that doesn't fix all problems because GNU Make also has a
> few built-in rules that are defined using pattern rules (because suffix
> rules are not powerful enough).  So a full list of "turn it all off"
> would be this:
> 
>   .SUFFIXES:
>   %:: %,v
>   %:: RCS/%,v
>   %:: RCS/%
>   %:: s.%
>   %:: SCCS/s.%
> 
> Hopefully these are just considered funnily-named targets and won't
> hurt anything, when used in non-GNU Make versions of make.
> 
> I admit this is annoying since it's possible that the catalog of built-
> in rules could change in the future.

It's also annyoing because it does not work portably: On FreeBSD and NetBSD,
'make' gives an error:

  make: don't know how to make %,v. Stop

Similarly on OpenBSD:

  make: don't know how to make %,v (prerequisite of: %)

Can we get a syntax to clear all built-in rules that works portably?
For example, such as:

  .SUFFIXES:
  .GNUSUFFIXES:

Bruno

Re: MAKEFLAGS=-r

[Bruno Haible]

David Boyce wrote:
> You say GNUMAKEFLAGS+=-r is "invalid syntax" but I don't know quite how to
> read that. It's not invalid in the sense of causing an error, it's just
> that it would be invisible to any non-GNU make program

Indeed, sorry. You're right. I confused it with the := assignment operator.

Bruno

Re: MAKEFLAGS=-r

[Bruno Haible]

David Boyce wrote:
> Everything else aside, there's a profound difference between MAKEFLAGS=-r
> and MAKEFLAGS+=-r. The latter is far less destabilizing.

At least the '-n' option does not get lost by MAKEFLAGS=-r. That is,
setting MAKEFLAGS=-r and running 'make -n' does not cause the actions
to be actually executed.

> And yes, GNUMAKEFLAGS is definitely better for this use.

But MAKEFLAGS+=-r or GNUMAKEFLAGS+=-r is not something one can use in a
Makefile.am, since this is invalid syntax for a POSIX make program.
Thus, for those who want to get rid of implicit rules because Automake
provides the rules already, it's either MAKEFLAGS=-r or nothing at all.

Bruno

Re: GNU make troubleshooting

[Bruno Haible]

Dmitry Goncharov wrote:
> > I believe these two user goals are so different; they belong in different
> > chapters.
> ...
> In other words, i don't see a chapter on how to avoid big debug output
> without optimizing the makefile.

Wait a second. "How to avoid big debug output?" is not one of the primary
questions a user asks themselves. (It's merely a guideline that one should
consider while writing troubleshooting documentation.) The primary user
question is "Which rules would be executed, and why?"

Another question, "What if a file was new?" can be answered through the '-W'
option, without producing big debug output.

Both of these questions have in common that they require Make to print
only the rules or actions that Make is considering. They don't require
Make to print the reasons why it is *not* considering this and that chain
of built-in rules.

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

No, I'm following the common engineering practice "analyze, then remedy".
"Analyze" means understanding what a Makefile will do in a certain situation,
and why. "Remedy" means to change the Makefile, based on that understanding.
If, during the analysis phase, the engineer modifies the Makefile, there
is a high chance that they will get to wrong conclusions and thus make
wrong changes.

A related engineering practice is "when experimenting, change only one
variable at a time". Because if they change two variables at once and get
and improvement, they won't know which variable change is responsible for it.

> 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

This is better for text under the topic "Understanding a Makefile's action".
Thanks.

Bruno

Re: MAKEFLAGS=-r

[Bruno Haible]

Dmitry Goncharov wrote:
> 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 premise "does not need built-in rules" is likely true for most Makefiles
generated by GNU Automake, because
  - GNU Automake generates its own rules already,
  - Whenever rules are executed that don't obey the variables listed in [1],
such as CPPFLAGS, it is a bug that the package's user should rightfully
report.

So I wondered whether I should add this variable definition in the Makefile.am
files of my GNU packages. But then I read this in the documentation [2]:

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

and

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

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

and this in Oracle's documentation [4]:

  "Do not define MAKEFLAGS in your makefiles."

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

> The manual should lead by example.

Yes, I agree. But if the example contradicts all the advice given in the rest
of the manual and elsewhere, I will certainly not use it in my Makefiles.

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? In other words, is it a good idea
to use MAKEFLAGS=-r in Makefiles that recurse to other Makefiles (and that
are maintained independently)?

Bruno

[1] 
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Preset-Output-Variables.html
[2] 
https://www.gnu.org/software/make/manual/html_node/Options_002fRecursion.html
[3] https://stackoverflow.com/questions/19611004/
[4] https://docs.oracle.com/cd/E19504-01/802-5880/make-65/index.html
[5] 
https://www.gnu.org/software/make/manual/html_node/Concept-Index.html#Concept-Index_cp_letter-M
[6] 
https://www.gnu.org/software/make/manual/html_node/Name-Index.html#Name-Index_fn_letter-M

Re: GNU make troubleshooting

[Bruno Haible]

Dmitry Goncharov wrote:
> > 1) The title, and what does the user want?
> This patch is not a full-fledged troubleshooting guide.
...
> > Is that really what I want to do and should do, as a user?
> i believe, makefile authors should apply these techniques.

OK, then it's appropriate to create *three* new sections:
  * In the chapter "Troubleshooting":
  - "Which rules would be executed, and why?"
  * In an appendix or chapter "Optimizing Makefiles"
  - "Disabling implicit rules entirely"
=> MAKEFLAGS
  - "Disabling implicit rules for a particular target"
=> makefile::;

The sections can have some overlap, e.g. all of these three will
use "make -n -d", but with different focus.

> How about "How to relieve make from redundant work and reduce the
> amount of debug output."?

I believe these two user goals are so different; they belong in different
chapters.

> My opinion is that, large amounts of debug output is not the problem.

I disagree: 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.)

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

Bruno

Re: GNU make troubleshooting

[Bruno Haible]

Hello Dmitry,

Dmitry Goncharov 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.

Thanks for trying to address this. However, your patch opens up a few
questions:

1) The title, and what does the user want?

> Appendix A Debug Output.
> 
> This section demonstrates how to simplify make debug output.

Good documentation that explains a feature or procedure should, IMO,
follow the "From the use-case to the details" principle.
https://gitlab.com/ghwiki/gnow-how/-/wikis/Documentation/Writing
The way it's written here, the user will wonder "Why should I read
this section?", "What can I expect from it?".

More broadly, here's a sketch how I could imagine a troubleshooting
chapter, with section titles *from the user's point of view* :

  Troubleshooting
  * Understanding a Makefile
- Which are the included sub-Makefiles?
- What is the total set of rules from the Makefile and all its included
  sub-Makefiles?
- What's the meaning of a certain expression with function invocations?
  * Understanding a Makefile's action w.r.t. a given file system state
- What are the values of the variables?
- Where is the Makefile source for each command that gets executed?
- Which actions would be executed?
- What if a file was not present?
- What if a file was new?
  * Understanding what happened in a build
- Which files were created in which order?
- Which files were read during the build? 
  * Making sense of specific error messages

I think your topic would fit in the second section, under a title such as
"Which rules would be executed, and why?"
That would be a better title than "Debug Output".

2)

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

What I get is:

$ make -d |tail +7 |wc
 46 2501921
$ make -d |tail +7 |wc
 35 1861458

So, subsequent invocations produce different results, because the state
on disk has changed. This is undesired, because when I (as a user) am
analyzing a Makefile (recall the section title
"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" ?

$ make -n -d |tail +7 |wc
 37 1831434
$ make -n -d |tail +7 |wc
 37 1831434

This way, it's reproducible.

3)

> Note, we added rule
> 
> makefile::;
> 
> This addition cut the debug output from 1338 to 730 lines.
> ...
> Finally, we can disable built-in rules Catalogue of Built-In Rules.
> 
> $ cat makefile
> MAKEFLAGS:=-r

Hey, you are modifying the Makefile in order to analyze how it works!
Is that really what I want to do and should do, as a user?

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

  $ make -n -d -r |tail +7 |wc

because that allows me to continue with an unmodified Makefile.

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

So that we arrive at the same 37 lines with a common of the form

  $ make -n -d SOME_MORE_OPTIONS | tail +7 | SOME_MORE_FILTER

?

Bruno

Re: GNU make troubleshooting

[Bruno Haible]

Alejandro Colomar wrote:
> In GNU Make, the "printf" statement is the
> $(info ...) function.  Maybe you didn't know about it?

Correct, I did not know about it. I created a 'dummy' target with an
echo command...

It would be really useful to collect all these various troubleshooting
tricks in a chapter "Troubleshooting" in the doc.

Bruno

Re: GNU make troubleshooting

[Bruno Haible]

Paul Smith wrote:
> > I get the same output with GNU make 4.4 as with 4.3.
> 
> Apologies for my mistake: I'm using the latest release (4.4.1).
> I tried your test:
> 
>   $ make --trace mbrtoc32.o
>   Makefile:1752: update target 'mbrtoc32.o' due to: target does not exist

With 4.4.1, I see this too. A nice improvement!

Bruno

Re: GNU make troubleshooting

[Bruno Haible]

Paul Smith wrote:
> Maybe a version difference.  I'm using 4.4.

I get the same output with GNU make 4.4 as with 4.3.

Bruno

Re: GNU make troubleshooting

[Bruno Haible]

Paul Smith wrote:
> Showing the "macroexpanded make sources" is difficult because make
> doesn't just expand an entire line then parse it.  Makefile syntax is
> context-sensitive so you can't know how or if to expand parts of a line
> until you've already expanded other parts.  Of course make could keep
> track of this for generating this kind of output.

If no perfect solution to this problem is possible, how about
implementing a simple approximation first, and then improve it based
on user feedback?

Because how is a GNU make user supposed to understand a Makefile and
the expansion of things like

   $(1): $$($(1)_OBJS) $$($(1)_LIBS:%=-l%)

or

   $(objpfx)$o$($o-version): $(objpfx)$o; $$(make-link)

if 'make' does not help them? [1]

> > 3) Single-stepping or tracing function execution.
> 
> Tracing is possible although if we just enable tracing for all variable
> expansion you'll get a TON of output.  Maybe the user could ask to
> trace expansion of certain things only.
> 
> I'm not interested in implementing an "interactive" mode for single-
> stepping GNU Make.  Maybe someone else wants to do it but my suspicion
> is that the code changes needed would be massively disruptive.

That sounds like a discussion among GNU make contributors could maybe
bring up alternative implementation ideas, that are not so disruptive?

Bruno

[1] https://www.gnu.org/software/make/manual/html_node/Eval-Function.html
[2] 
https://sourceware.org/git/?p=glibc.git;a=blob;f=Makerules;h=018780c818cab0d4626e31308f013582114fca4f;hb=HEAD#l1043

Re: GNU make troubleshooting

[Bruno Haible]

Paul Smith wrote:
> It's not acceptable (to me) to only show the one newest file, not all
> files that are newer than the target, because often you want to know
> all the newer files.

You say "It's not acceptable (to me) to only show the one newest file",
and I say "A tool that shows me 3.7 KB worth of file names in one line
is useless to me, because that is information overload, and I don't
have good filtering skills".

It's a bit like one gdb user saying "I want to see the values of all
local variables on the stack, because I often need them" and another
person saying "If the output is 100 lines long or longer, you lost me".

How about introducing _options_ whose goal is not to produce maximal
information, but small-sized and still useful information?

Bruno

Re: GNU make troubleshooting

[Bruno Haible]

> 2) Where is the Makefile source for each command that gets executed?
>For each command that gets executed, print not only the command (or
>nothing if the line begins with '@'), but also the location (which
>Makefile, which line number).
> 
>This would help in a number of situations.
> 
>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.

Just learned about the '--trace' option and I have two comments:

* It should be described in a chapter "Troubleshooting". Mentioning it
  in section "Summary of Options" is not enough.

* Some of its output is good; some of its output is useless:

$ rm mbrtoc32.o
$ make --trace mbrtoc32.o 
Makefile:1752: update target 'mbrtoc32.o' due to: ../../gllib/mbrtoc32.c 
/usr/include/stdc-predef.h ../config.h 
/usr/lib/gcc/x86_64-linux-gnu/11/include/stdbool.h /usr/include/assert.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 uchar.h /usr/include/uchar.h 
stddef.h /usr/lib/gcc/x86_64-linux-gnu/11/include/stddef.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/mbstate_t.h 
/usr/include/x86_64-linux-gnu/bits/types/__mbstate_t.h 
/usr/lib/gcc/x86_64-linux-gnu/11/include/stdint.h /usr/include/stdint.h 
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h 
/usr/include/x86_64-linux-gnu/bits/wchar.h 
/usr/include/x86_64-linux-gnu/bits/stdint-intn.h 
/usr/include/x86_64-linux-gnu/bits/stdint-uintn.h wchar.h /usr/include/wchar.h 
/usr/include/x86_64-linux-gnu/bits/floatn.h 
/usr/include/x86_64-linux-gnu/bits/floatn-common.h 
/usr/lib/gcc/x86_64-linux-gnu/11/include/stdarg.h 
/usr/include/x86_64-linux-gnu/bits/types/wint_t.h 
/usr/include/x86_64-linux-gnu/bits/types/__FILE.h 
/usr/include/x86_64-linux-gnu/bits/types/FILE.h 
/usr/include/x86_64-linux-gnu/bits/types/locale_t.h 
/usr/include/x86_64-linux-gnu/bits/types/__locale_t.h 
/usr/include/x86_64-linux-gnu/bits/wchar2.h /usr/include/string.h 
/usr/include/strings.h /usr/include/x86_64-linux-gnu/bits/strings_fortified.h 
/usr/include/x86_64-linux-gnu/bits/string_fortified.h /usr/include/wctype.h 
/usr/include/x86_64-linux-gnu/bits/wctype-wchar.h 
/usr/include/x86_64-linux-gnu/bits/endian.h 
/usr/include/x86_64-linux-gnu/bits/endianness.h ../../gllib/attribute.h 
/usr/include/errno.h /usr/include/x86_64-linux-gnu/bits/errno.h 
/usr/include/linux/errno.h /usr/include/x86_64-linux-gnu/asm/errno.h 
/usr/include/asm-generic/errno.h /usr/include/asm-generic/errno-base.h 
/usr/include/x86_64-linux-gnu/bits/types/error_t.h stdlib.h 
/usr/include/stdlib.h /usr/include/x86_64-linux-gnu/bits/waitflags.h 
/usr/include/x86_64-linux-gnu/bits/waitstatus.h sys/types.h 
/usr/include/x86_64-linux-gnu/sys/types.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/endian.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/select2.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/alloca.h 
/usr/include/x86_64-linux-gnu/bits/stdlib-bsearch.h 
/usr/include/x86_64-linux-gnu/bits/stdlib-float.h 
/usr/include/x86_64-linux-gnu/bits/stdlib.h ../../gllib/localcharset.h 
../../gllib/streq.h ../../gllib/hard-locale.h locale.h /usr/include/locale.h 
/usr/include/x86_64-linux-gnu/bits/locale.h ../../gllib/setlocale_null.h 
../../gllib/arg-nonnull.h
gcc -ftrapv -DHAVE_CONFIG_H -I. -I../../gllib -I..  -DGNULIB_STRICT_CHECKING=1 
-I/media/develdata/devel/inst-x86_64-64/include -Wall  -g -O2 -MT mbrtoc32.o 
-MD -MP -MF .deps/mbrtoc32.Tpo -c -o mbrtoc32.o ../../gllib/mbrtoc32.c
mv -f .deps/mbrtoc32.Tpo .deps/mbrtoc32.Po

The part 

GNU make troubleshooting

[Bruno Haible]

Hi all,

In recent build system discussions on gnu-prog-discuss, the suggestion was
made [1] to use GNU make's power instead of autoconf, automake, and POSIX make.

I think GNU make is lacking transparency / debuggability / serviceability
features before this suggestion makes sense. Especially for newbie users
and complex makefiles.

I know about, and have occasionally used, the GNU make options
  -n, --dry-run
  -d
  -p
  -t, --touch
and they don't fulfil my needs.

In particular, four aspects of transparency / debuggability / serviceability
are lacking in GNU make.

1) Print the total of the Makefile and all included Makefiles.
   Like what "gcc -E" does with C code.
   I don't need this when using Automake, because Automake resolves the
   'include' statements before generating a Makefile. But if people advocate
   to use GNU make without Automake, it becomes a requirement. As a developer,
   I don't want to check each 'include' statement, recursively, manually.
   A tool should do that.

   This would also answer a question on #gnu today:
   "Is there a way to figure out where the rule is coming from? The main
issue is "target file 'clean' has both : and :: entries. Stop." But
I'm unable to figure out where the last clean: target is coming from."

   Probably this facility should have an option to show the macroexpanded /
   not macroexpanded Makefile sources.

2) Where is the Makefile source for each command that gets executed?
   For each command that gets executed, print not only the command (or
   nothing if the line begins with '@'), but also the location (which
   Makefile, which line number).

   This would help in a number of situations.

   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.

3) Single-stepping or tracing function execution. One project (GNU libc)
   makes profound use of GNU make functions, and it was always painful
   for me to understand what results to expect from a complex use of
   $(foo ...). Even from the simple text-manipulating functions [2].

   There is an option --eval=STRING, but I don't think it fulfils the
   need.

4) A documentation chapter regarding troubleshooting, that explains
   how to understand what 'make' is doing in a particular case.
   Chapters 2-8 and 10-12 explain how to set up the input to 'make'.
   Chapters 9 and 13 explain operational aspects, but none goes into
   troubleshooting details.
   For a complex program like GNU make, probably at least 10 or 20 pages
   on this topic are needed.

Best regards,

Bruno

[1] https://www.airs.com/blog/archives/95
[2] https://www.gnu.org/software/make/manual/html_node/Functions.html

Re: GNU Make 4.4.0.91 on openSUSE Leap 15.2

[Bruno Haible]

Paul Smith wrote:
> In the abstract it would be nice to have configure detect the bug in
> glibc and use our local version of glob on those systems, but writing a
> runtime test for the actual bug would be "interesting".

gnulib/m4/glob.m4 contains a test for this bug:

  AC_CACHE_CHECK([whether glob lists broken symlinks],
 [gl_cv_glob_lists_symlinks],
[if test $cross_compiling != yes; then
   if ln -s conf-doesntexist conf$$-globtest 2>/dev/null; then
 gl_cv_glob_lists_symlinks=maybe
   else
 # If we can't make a symlink, then we cannot test this issue.  Be
 # pessimistic about this.
 gl_cv_glob_lists_symlinks=no
   fi
   if test $gl_cv_glob_lists_symlinks = maybe; then
 AC_RUN_IFELSE(
   [AC_LANG_PROGRAM(
  [[#include 
#include ]],
  [[glob_t found;
if (glob ("conf*-globtest", 0, NULL, ) == 
GLOB_NOMATCH)
  return 1;
globfree ();
  ]])],
   [gl_cv_glob_lists_symlinks=yes],
   [gl_cv_glob_lists_symlinks=no],
   [dnl We don't get here.
:
   ])
   fi
   rm -f conf$$-globtest
 else
   gl_cv_glob_lists_symlinks="$gl_cross_guess_normal"
 fi
])

GNU Make 4.4.0.91 on other platforms

[Bruno Haible]

All tests pass on:

  - Ubuntu 22.04

  - CentOS 8 stream
I.e. the 3 test failures reported in
https://lists.gnu.org/archive/html/bug-make/2023-01/msg00097.html are gone.

  - CentOS Stream 9

  - Manjaro 17
I.e. the bi-arch problem reported in
https://lists.gnu.org/archive/html/bug-make/2023-01/msg00101.html is fixed.

  - macOS 12.5
I.e. the 2 test failures reported in
https://lists.gnu.org/archive/html/bug-make/2023-01/msg00108.html are gone.

  - FreeBSD 11, NetBSD 9, OpenBSD 6.5

  - Solaris 10

Bruno

Re: GNU Make 4.4.0.91 on Solaris 11.4 (32-bit)

[Bruno Haible]

Paul Smith wrote:
> > Somehow your fix for archives.12 and archives.13 does not work
> > in this environment. I'm attaching the config.status.
> 
> That test was accidentally running with 4.4.0.90 still:

Oops, sorry.

Retested Solaris 11.4 with your latest tests/scripts/features/archives patch.
Results:
  - 64 bit: All tests pass.
  - 32 bit: All tests pass.

Yeah!

Bruno

Re: GNU Make 4.4.0.91 on GNU/Hurd

[Bruno Haible]

Paul Smith wrote:
> > Yes, I see these also on:
> >   - Debian 11.1
> >   - Solaris 11.4 (64-bit)
> >   - Solaris 11 OmniOS
> >   - Solaris 11 OpenIndiana
> 
> The patch below should fix it but it's probably not worth the effort of
> retesting all these systems.

I've retested one of the systems: Solaris 11.4 (64-bit).
Your patch fixes the two remaining test failures. Now, all tests pass.

Bruno

GNU Make 4.4.0.91 on Solaris 11.4 (32-bit)

[Bruno Haible]

On Solaris 11.4 (32-bit mode):
All 4 test failures in category 'features/archives', reported in
,
are still present.

Somehow your fix for archives.12 and archives.13 does not work
in this environment. I'm attaching the config.status.



makeerror-4.4.0.90-x86_64-pc-solaris2.11-avnc.tar.gz
Description: application/compressed-tar


config.status
Description: application/shellscript

Re: GNU Make 4.4.0.91 on GNU/Hurd

[Bruno Haible]

Paul Smith wrote:
> > Only 2 test failures, in category 'features/archives', due to "cc:
> > not found".
> 
> Argh, I forgot to change the CC thing everywhere in that test.  I've
> fixed this.
> 
> You'll likely see this same issue with the other systems that don't
> provide a "cc".

Yes, I see these also on:
  - Debian 11.1
  - Solaris 11.4 (64-bit)
  - Solaris 11 OmniOS
  - Solaris 11 OpenIndiana

Bruno

GNU Make 4.4.0.91 on openSUSE Leap 15.2

[Bruno Haible]

On openSUSE Leap 15.2, the results are better than with 4.4.0.90
:

- The wildcard.9 failure (well-known),
- 2 failures in the 'features/archives' category, due to
  "cc: command not found".



makeerror-4.4.0.91-x86_64-pc-linux-gnu-ex0u.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.91 on AIX 7.2

[Bruno Haible]

Paul Smith wrote:
> Does touch on AIX support the "-a" option?

Yes. "-a" is a documented option of /usr/bin/touch, and it works fine.

Bruno

GNU Make 4.4.0.91 on AIX 7.2

[Bruno Haible]

On AIX 7.2 as well, the results are much better than for 4.4.0.90
:

Only 3 test failures:
  - 2 from category 'features/archives', due to "cc:  not found"
  - 1 from category 'features/include'.



makeerror-4.4.0.91-powerpc-ibm-aix7.2.4.0-h67e.tar.gz
Description: application/compressed-tar


makeerror-4.4.0.91-powerpc-ibm-aix7.2.4.0-oo5n.tar.gz
Description: application/compressed-tar

GNU Make 4.4.0.91 on Cygwin

[Bruno Haible]

On Cygwin (running in Windows 10), the results are much better than those
of 4.4.0.90 :

All "Device or resource busy" failures are gone. Only the 1 failure in
category 'misc/general4' is still present.



makeerror-4.4.0.91-x86_64-pc-cygwin-gcml.tar.gz
Description: application/compressed-tar

GNU Make 4.4.0.91 on GNU/Hurd

[Bruno Haible]

On GNU/Hurd, much fewer test failures than with 4.4.0.90
:

Only 2 test failures, in category 'features/archives', due to "cc: not found".



makeerror-4.4.0.91-i686-unknown-gnu0.9-0wnh.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on GNU/Hurd

[Bruno Haible]

Paul Smith wrote:
> > In other words, on GNU/Hurd, one should use 'glob' and 'globfree',
> > not 'glob64' and 'globfree64'. Even though the libc is glibc and
> > support for large files (> 2 GiB) is enabled.
> > 
> > The culprit seems to be the glob.in.h file.
> 
> As far as I can tell from the logging you sent, GNU make has correctly
> detected that the system library is glibc and so it will not use any
> part of the internal globbing library, including the glob.in.h file.
> 
> In other words, there should be no glob.h file in the GNU make build
> directories and the glob.h that read.c includes should be the system
> glob.h, and there will be no glob.o added to the libgnu.a library.

You're entirely right.

> If I'm right, then the error you're seeing must come from the system's
> glob implementation, somehow.

Yes. Reported as a glibc bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=30146

Bruno

Re: Regression on Cygwin: Problems with parallel make in 4.4

[Bruno Haible]

Paul Smith wrote:
> I've made a change that causes GNU/Hurd to not use the mkfifo()-based
> jobserver, and go back to using pipe().

That's nice, because compared to the previous results

  - 4 failures in category 'features/archives', due to "cc: not found".
  - 5 failures in category 'features/jobserver'
  - 2 failures in category 'features/parallelism'
  - 1 failure in category 'features/recursion'
  - 1 failure in category 'functions/shell'

with a default jobserver_style = "pipe", I get

  - 4 failures in category 'features/archives', due to "cc: not found".
  - 4 failures in category 'features/jobserver'
  - 2 failure in category 'functions/shell'

Bruno


makeerror-4.4.0.90-i686-unknown-gnu0.9-aonj.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on GNU/Hurd

[Bruno Haible]

I wrote:
> On GNU/Hurd (from 2022), I get 13 test failures:
> 
> New:
> 
>   - 4 failures in category 'features/archives', due to "cc: not found".
> 
> Already reported in
> https://lists.gnu.org/archive/html/bug-make/2022-10/msg00218.html :
> 
>   - 5 failures in category 'features/jobserver'
>   - 2 failures in category 'features/parallelism'
>   - 1 failure in category 'features/recursion'
>   - 1 failure in category 'functions/shell'

Note that on this platform, the build log has a warning:

gcc-12  -g -O2 -Wl,--export-dynamic -L/home/bruno/lib -o make 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/posixos.o  src/remote-stub.o   
lib/libgnu.a   
/usr/bin/ld: src/read.o: in function `parse_file_seq':
/home/bruno/make-4.4.0.90/build/../src/read.c:3472: warning: glob64 is not 
implemented and will always fail

In other words, on GNU/Hurd, one should use 'glob' and 'globfree',
not 'glob64' and 'globfree64'. Even though the libc is glibc and
support for large files (> 2 GiB) is enabled.

The culprit seems to be the glob.in.h file.

Bruno

Re: Regression on Cygwin: Problems with parallel make in 4.4

[Bruno Haible]

Paul Smith wrote:
> > And possibly also on GNU/Hurd. Cf.
> > https://lists.gnu.org/archive/html/bug-make/2023-01/msg00107.html
> 
> I may be misremembering but I thought that you had tried forcing the
> pipe jobserver option on GNU/Hurd and it didn't help.

This must be a misunderstanding. I never said that. I don't even know
how to do this, within the framework of GNU make's test suite.

All I said was, comparing the Cygwin failures with the GNU/Hurd failures [1]:
  "In all these failures, where we see an error message "Leftover temporary
   files" in GNU/Hurd, we see "Device or resource busy" in Cygwin."

Bruno

[1] https://lists.gnu.org/archive/html/bug-make/2023-01/msg00134.html

Re: Regression on Cygwin: Problems with parallel make in 4.4

[Bruno Haible]

Ken Brown wrote:
> I suggest 
> that you provide a configure option to set the jobserver style at the 
> time make is built, and set it to 'pipe' by default on Cygwin.

And possibly also on GNU/Hurd. Cf.
https://lists.gnu.org/archive/html/bug-make/2023-01/msg00107.html

Bruno

Re: OpenIndiana installation

[Bruno Haible]

Paul Smith wrote:
> I had a Solaris11 OVA and I ran the pkg
> install developer/gcc-11 and it did lots of things but afterward there
> was no gcc program installed (I searched the entire disk for "*gcc*").
> Weird.

On Solaris 11 from Oracle, "pkg search /usr/bin/gcc" and
"pkg search /usr/bin/g++" told me that what I need is package
'developer/gcc/gcc-c++', so there I did
  sudo pkg install developer/gcc/gcc-c++

> So then I installed OpenIndiana based on your notes and that succeeded
> and I was able to build make and run the tests.
> 
> Unfortunately I wasn't able to reproduce the problem; all tests passed
> for me (I'm using a build where the ar issue is already fixed).  I
> tried with 1 CPU as well just to be sure.
> 
> Sigh!
> 
> I wonder what can be different about what I'm doing and what you're
> doing.

At this point I am out of clues too. Maybe it's related to the speed
of the CPU (e.g. execution speed vs. context switch speed ratio)?

> Maybe it's related to how the tests are run; I suppose you're
> using some sort of automated testing framework?  Maybe there's no TTY
> or something?  Can you briefly describe how the tests are invoked?

In a session with a TTY (GUI terminal in OpenIndiana, plain console in
Solaris 11.4), I run a /bin/sh script that contains these lines:

=
#!/bin/sh
test -f configure || { echo "This script must be invoked from a configurable 
package." 1>&2; exit 1; }
rm -rf build-64-gcc
mkdir build-64-gcc
cd build-64-gcc
$HOME/configure-64-gcc "$@" 2>&1 | tee log1 \
&& gmake 2>&1 | tee log2 \
&& gmake check 2>&1 | tee log3
=

Sometimes I also do "gmake check" without the redirection; there's
normally no difference between with and without redirection.

Bruno

Re: CentOS Stream installation

[Bruno Haible]

Paul Smith wrote:
> How many CPUs did you give to the VM?  It shouldn't matter since we're
> doing multiprocessing here but... maybe...?  I was using 4G RAM and 4
> CPUs in my guest.

I am using 1 CPU in that VM.

> > I never install the VirtualBox guest additions. The downside is that
> > sharing data is less comfortable (I use 'scp' each time), and that
> > the mouse handling is a bit more annoying.
> 
> The problem is that I can't seem to open connections from my host
> machine to the guest machine: my host machine can't find the guests via
> any IP address I can come up with.

Yes, by default, in VirtualBox, you only have connectivity from the guest
to the host. For connectivity from the host to the guest, there appear to
be two approaches:
  - Give each guest a distinct IP address (means: list the guests in your
LAN's DHCP server), and choose a "bridged" network adapter for each
VM. Note: In my experience (with older versions of VirtualBox) this
works fine when the host has an Ethernet network card, but not with
a Wi-Fi network adapter.
  - Use the "Advanced > Port forwarding" setting, even with a "NAT" network
adapter. The host port number must be > 1024.
Web searches for "virtualbox ssh into vm" or "virtualbox ssh from host to guest"
give some pointers.

Also, don't forget that many guest OSes have a built-in firewall. If from
within the guest VM, "ssh localhost" works but from the host, ssh to the VM
never responds, then this is the problem. In this case, you will need to "open"
the port 22 there. For older Linux distro the command to do it is
  sudo iptables -I INPUT -p tcp -m tcp --dport 22 -j ACCEPT
For CentOS 8 probably something like
  sudo nft add rule inet firewalld filter_IN_public_allow tcp dport 22 accept

> And normally I don't have an SSH server running on my host machine,
> since I don't need to log into it from anywhere and it's more secure
> that way

Yeah, everyone has different preferences. Leading to different network
topologies in each case.

Bruno

Re: CentOS Stream installation

[Bruno Haible]

Hi Paul,

> It would be good to know whether you are testing CentOS Sream 8 or 9.

I am testing CentOS 8 stream. Find my personal installation notes below.

> I am not able to install CentOS Stream 9 in VirtualBox and get the
> guest additions to work so I can mount a shared partition.  Half the
> time it freezes halfway through the install, and if it does go through
> the guest additions fail to compile their kernel modules (mismatched
> Linux kernel headers).

I never install the VirtualBox guest additions. The downside is that
sharing data is less comfortable (I use 'scp' each time), and that the
mouse handling is a bit more annoying.

Bruno

= CentOS 8 in VirtualBox ==
Use CentOS 8 stream 2022-10-05 from 
https://ftp.gwdg.de/pub/linux/centos/8-stream/isos/x86_64/

Disk size: 15 GB.

The installation menu is in a stupid order: Can only enable NTP servers
after networking is enabled! Therefore do things in this order:

Installation Destination:
Storage Configuration: Custom
Standard Partition  14 GiB (14336 MiB)  /  ext4
Standard Partition  1  GiB (1024 MiB)   swap

KDump:
Disable kdump.

Network & host name:
Enable networking.
Ethernet config: General > Enable "Connect automatically".
Host name: centos8s

Time & Date:
Set time zone.
Disable then Enable "Network Time".

Installation Source:
On the network, https://ftp.gwdg.de/pub/linux/centos/8-stream/BaseOS/x86_64/os/
URL type: repository URL
Deselect AppStream.
Select AppStream.

Software selection:
  Base Environment: Workstation
  Add-ons: Development Tools, Graphical Administration Tools

Root password:
  login: root
  password: 
  Press "Done" twice.

User settings:
  login: 
  password: 
  Select "Make this user administrator".
  Press "Done".

Click "Begin installation".

Wait for the installation to complete.

Power off. Eject CD.

Welcome wizard:
  Privacy: Location services: off.

Popup menu > Settings > Privacy > Screen Lock
Automatic screen lock = Off

Popup menu > Settings > Power > Power Saving
Blank screen = Never

Power Off. Reboot.

Activities > Software > Updates: Refresh. -> Up to date.

Activities > Software

Search: GNU Emacs, install
Search: gVim, install

$ dnf list
# Not needed:
#$ sudo dnf install make
#$ sudo dnf install gcc
#$ sudo dnf install gcc-c++

Power Off.

Re: OpenIndiana installation

[Bruno Haible]

Paul Smith wrote:
> I tried to install Solaris 11 OpenIndiana from an OVA file in
> VirtualBox and I was able to get it to install but couldn't figure out
> how to install a C compiler on it.

Yes, every OS has its own type of package manager and, with it, its own
way of finding out the actual package names that one needs to install.

I hope my writeup (below) helps.

Bruno

=== Solaris 11 OpenIndiana in VirtualBox 
OpenIndiana, a distro based on Illumos - roughly Solaris 11 compatible.

Download: 
http://dlc.openindiana.org/isos/hipster/20221123/OI-hipster-gui-20221123.iso

Getting started doc: http://docs.openindiana.org/handbook/getting-started/

Disk size: 16 GB
RAM size: 3 GB (with just 1.5 GB 'pkg install' runs out of RAM, with just 2 GB 
it hangs)


Run installer 'Install OpenIndiana'.

Root password: 

Login: **
Password: 

Host name: 

Eject CD/DVD. Reboot.

System > Preferences > Hardware > Power Management
  > On AC Power > Display > Put display to sleep when inactive for: Never
System > Preferences > Look and Feel > Windows
  > Behaviour > Window Selection > Select windows when the mouse moves over 
then: on

Reboot.

$ pkg search /usr/bin/gcc
$ pkg search /usr/bin/g++
$ pkg search /usr/include/stdio.h
$ pkg search /usr/bin/gdb
$ pkg search /usr/bin/emacs
$ pkg search /usr/bin/clang
See also https://pkg.openindiana.org/hipster/en/index.shtml

$ sudo pkg install developer/gcc-11
$ sudo pkg install system/header
$ sudo pkg install developer/debug/gdb
$ sudo pkg install editor/gnu-emacs
$ sudo pkg install developer/clang-13

Re: GNU Make 4.4.0.90 on AIX 7.2

[Bruno Haible]

> * 1 failure in category 'features/include'.
>   The command 'touch -a test.foo' is being printed twice, not just once.
>   This could be a bug in the AIX exec* functions, which don't properly
>   separate the stdout and stderr of the parent process and child process
>   in some situations. (I had seen this many years ago, in AIX 4 or AIX 5.)

config.h contains:
/* #undef USE_POSIX_SPAWN */

Replacing 'vfork ()' with 'fork ()' in src/job.c does not help.

Bruno

Re: GNU Make 4.4.0.90 on Cygwin

[Bruno Haible]

On Cygwin 2.9.0 (running in Windows 10), I see these test failures:

* Same failures as seen in GNU/Hurd:

  - 5 failures in category 'features/jobserver'
  - 2 failures in category 'features/parallelism'
  - 1 failure in category 'features/recursion'
  - 1 failure in category 'functions/shell'

  In all these failures, where we see an error message "Leftover temporary 
files" in GNU/Hurd,
  we see "Device or resource busy" in Cygwin.

* Other failures:

  - 1 failure in category 'misc/general4'.
Maybe because after deleting PATH, no 'echo' command is found any more.

Find attached the logs.


makeerror-4.4.0.90-x86_64-pc-cygwin-26a2.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on AIX 7.2

[Bruno Haible]

On AIX 7.2, in 64-bit mode, with the environment variables settings

  CC="xlc -q64 -qthreaded -qtls";
  CXX="xlC -q64 -qthreaded -qtls";
  AR="ar -X 64";
  NM="nm -X 64 -B";
  export CC CXX AR NM

(with which I build many GNU packages successfully), I get 20 test failures:

* 16 failures in category 'features/archives'.
  Error message:
/home/haible/make-4.4.0.90/build-64-xlc/tests/../make: invalid option -- X
Usage: make [options] [target] ...
Options:
...
  Apparently the value of ${AR} or the value of ${NM} is being decomposed, and
  the -X option, meant for the 'ar' or the 'nm' program, is being passed to
  'make'.

* 1 failure in category 'features/include'.
  The command 'touch -a test.foo' is being printed twice, not just once.
  This could be a bug in the AIX exec* functions, which don't properly
  separate the stdout and stderr of the parent process and child process
  in some situations. (I had seen this many years ago, in AIX 4 or AIX 5.)

* 3 failures in category 'features/output-sync'.
  Error message is "timeout after 10 seconds".

Find attached the logs.



makeerror-4.4.0.90-powerpc-ibm-aix7.2.4.0-8cot.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on Solaris 11 OpenIndiana

[Bruno Haible]

On Solaris 11 OpenIndiana (from 2022), aside from the 4 well-known test
failures in 'features/archives', in 64-bit mode I also see a test failure
in category 'features/output-sync', with an error message
"timeout after 10 seconds".

I don't know why only this 1 out of 3 output-sync tests (compared with
OmniOS) and why only in 64-bit mode.

Find attached the logs.


makeerror-4.4.0.90-x86_64-pc-solaris2.11-nx4l.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on Solaris 11 OmniOS

[Bruno Haible]

On Solaris 11 OmniOS, aside from the well-known 4 features/archives failures,
I see 3 test failures in the 'features/output-sync' category. They come
with an error message "timeout after 10 seconds".

Here the logs:
  - 32-bit build: makeerror-4.4.0.90-x86_64-pc-solaris2.11-thix.tar.gz
  - 64-bit build: makeerror-4.4.0.90-x86_64-pc-solaris2.11-hhav.tar.gz

These 3 failures were already seen at
.


makeerror-4.4.0.90-x86_64-pc-solaris2.11-thix.tar.gz
Description: application/compressed-tar


makeerror-4.4.0.90-x86_64-pc-solaris2.11-hhav.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on Solaris 11.4

[Bruno Haible]

The same 4 failures in features/archives ("cc: not found") also occur
on Solaris 11.4. On this platform, 'cc' does not exist in $PATH, but 'gcc'
does.

Find attached the logs.



makeerror-4.4.0.90-x86_64-pc-solaris2.11-q6is.tar.gz
Description: application/compressed-tar

Re: GNU/Hurd installation

[Bruno Haible]

Paul Smith wrote:
> > I'll try downloading the 2022-08-24
> > version you reference above and see if that makes a difference.
> 
> It did not matter: same hang.  There's clearly some magic pixie dust
> that needs to be sprinkled on my system to get this to work, that I do
> not have.

Unfortunately, this magic pixie dust depends on your CPU model, UEFI/BIOS
settings, Linux host kernel version, and VirtualBox version. I've had VMs
that became unbootable after moving to a newer hardware, and vice versa.
The VirtualBox documentation [1] gives a certain amount of background
knowledge, which is then the basis for finding the right setting that
makes things work.

Sorry, I had expected that it would be as smooth for you as it was for me.

Bruno

[1] https://www.virtualbox.org/manual/UserManual.html

Re: GNU/Hurd installation

[Bruno Haible]

Paul Smith wrote:
> I've tried a couple of times, using different instructions (VirtualBox
> and vanilla KVM) and every time when it starts to boot the first time
> (after selecting this install) it prints:
> 
>   ...
>   module 0: initrd $(ramdisk-create)
>   rd0: 13279232 bytes @fa491
>   module 1: ext2fs ...
>   module 2: exec $(exec-task=task-create)
>   3 multiboot modules
>   task loaded: ext2fs ...
>   zip:device:rd0
>   task loaded: exec
> 
>   start ext2fs: _
> 
> and hangs there.

In my instructions for GNU/Hurd in 2020 I had noted
  Disable 'Nested paging', otherwise it DOES NOT BOOT!

So, maybe it's worth looking at the main parameters of the VirtualBox VM:
  - General: Operating System: Other/Unknown
  - System: Motherboard: *Disable* all extended features (I/O APIC, EFI)
  - System: Processor: *Disable* all extended features (PAE/NX, Nested VT-x)
[The latter is what I meant above.]
  - System: Paravirtualization Interface: You can try different values
than 'Default'.

Do you have other VirtualBox VMs that work? If not, i.e. if you get problems
also with other OSes as guests, I would verify that VT-x/AMD-V is enabled in
the UEFI/BIOS.

Bruno

Re: GNU/Hurd installation

[Bruno Haible]

Paul Smith wrote:
> I will download a GNU/Hurd KVM image, as suggested here:
> 
> https://www.debian.org/ports/hurd/hurd-cd
> 
> is that appropriate for testing?

Yes.

The GNU/Hurd installation instructions vary a bit over time, but these are
my notes from 5 months ago. Fill in the ** fields.

 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Download 
https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/20220824/debian-sid-hurd-i386-DVD-1.iso

Start VirtualBox. Create new VM.

Disk size: 8 GB

Pseudo-graphical install.
Language: English
Location: United States
Keymap: American English
Hostname: **
Domain name: **

No root account.
login: **
password: **

Accept a dummy time zone.

Partitioning: Entire disk. All files in one partition.

Software selection: Debian desktop environment. (Well, that was not necessary,
as I didn't really get the desktop running later.)

Reboot. Eject CD-ROM.

Set time zone: sudo dpkg-reconfigure tzdata

Install packages:
Insert CD-ROM, boot, "Boot from first hard disk".
$ sudo apt install g++-12 gdb make vim
$ sudo apt install emacs # not available

Package list for further packages:
https://packages.debian.org/en/sid/

Re: GNU Make 4.4.0.90 on macOS 12

[Bruno Haible]

On macOS 12.5 / arm64 I see two test failures:
  - output-sync
  - temp_stdin

Find attached the log files. The machine is gcc104.fsffrance.org.



makeerror-4.4.0.90-aarch64-apple-darwin21.6.0-050w.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on GNU/Hurd

[Bruno Haible]

On GNU/Hurd (from 2022), I get 13 test failures:

New:

  - 4 failures in category 'features/archives', due to "cc: not found".

Already reported in
https://lists.gnu.org/archive/html/bug-make/2022-10/msg00218.html :

  - 5 failures in category 'features/jobserver'
  - 2 failures in category 'features/parallelism'
  - 1 failure in category 'features/recursion'
  - 1 failure in category 'functions/shell'



makeerror-4.4.0.90-i686-unknown-gnu0.9-e2ai.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on Debian 11.1

[Bruno Haible]

Paul Smith wrote:
> > But instead I see 4 test failures in the 'features/archives'
> > category.
> 
> These are because:
> 
>   ! /bin/sh: 1: cc: not found
> 
> Why is there no C compiler on this system?  Or is the problem that it's
> not on the PATH for some reason?

Indeed, there is no 'cc' nor 'gcc' in $PATH on this system. The reason is
that several C compilers can be chosen. I installed GCC 10, and then set the
environment variable
  CC="gcc-10"
and this is found in $PATH, as /usr/bin/gcc-10.

Per GNU standards [1], a GNU package should use $CC, not 'cc' — so that users
have the freedom to use a compiler of their choice (clang, TinyCC, whatever...).

In this test you have the lines

  # Fallback if configure did not find AR
  my $ar = get_config('AR') || 'ar';

Why not do the same for CC?

  my $cc = get_config('CC') || 'cc';

Bruno

[1] https://www.gnu.org/prep/standards/html_node/Configuration.html

Re: GNU Make 4.4.0.90 on Manjaro 17 — bi-arch problem

[Bruno Haible]

On Manjaro Linux 17, installed from manjaro-kde-17.1.12-stable-x86_64.iso,
in 32-bit mode, the build failure reported in
  https://lists.gnu.org/archive/html/bug-make/2022-10/msg00212.html
still occurs. Find the build details attached.



makeerror-manjaro17-32bit.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on openSUSE Leap 15.2

[Bruno Haible]

On OpenSUSE Leap 15.2 / x86_64 (a glibc 2.26 system):

- The wilcard.9 failure reported in
  https://lists.gnu.org/archive/html/bug-make/2022-10/msg00128.html
  and discussed in
  https://lists.gnu.org/archive/html/bug-make/2022-10/msg00158.html
  is still present.

- The output-sync and temp_stdin failures reported at that time are
  gone.

- There are 4 new failures in the 'features/archives' category. Looks
  similar to those just reported in
  https://lists.gnu.org/archive/html/bug-make/2023-01/msg00098.html .



makeerror-4.4.0.90-x86_64-pc-linux-gnu-bgji.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on Debian 9.1

[Bruno Haible]

On Debian 9.1.0 / x86 (a machine with glibc 2.24):

- The wilcard.9 failure reported in
  https://lists.gnu.org/archive/html/bug-make/2022-10/msg00123.html
  and discussed in
  https://lists.gnu.org/archive/html/bug-make/2022-10/msg00158.html
  is still present.

- The output-sync and temp_stdin failures reported at that time are
  gone (already gone in
  https://lists.gnu.org/archive/html/bug-make/2022-10/msg00208.html ).

- There are 4 new failures in the 'features/archives' category. Looks
  similar to those just reported in
  https://lists.gnu.org/archive/html/bug-make/2023-01/msg00098.html .



makeerror-4.4.0.90-i686-pc-linux-gnu-ryj5.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on Debian 11.1

[Bruno Haible]

On Debian 11.1 / x86_64 (a glibc 2.31 system) I don't see the
older test failures from
  https://lists.gnu.org/archive/html/bug-make/2022-10/msg00124.html
any more. But instead I see 4 test failures in the 'features/archives'
category.

Find the logs attached.




makeerror-4.4.0.90-x86_64-pc-linux-gnu-7l0o.tar.gz
Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on CentOS Stream

[Bruno Haible]

On CentOS stream, 3 tests fail, in the output-sync category.

Find attached the logs:
  - with gcc: makeerror-4.4.0.90-x86_64-pc-linux-gnu-itaa.tar.gz
  - with clang: makeerror-4.4.0.90-x86_64-pc-linux-gnu-dzg1.tar.gz

It looks similar to what I reported in
https://lists.gnu.org/archive/html/bug-make/2022-10/msg00125.html .


makeerror-4.4.0.90-x86_64-pc-linux-gnu-itaa.tar.gz
Description: application/compressed-tar


makeerror-4.4.0.90-x86_64-pc-linux-gnu-dzg1.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on Solaris 11

[Bruno Haible]

Dmitry Goncharov wrote:
> >   - On Solaris 11 OmniOS, there are only 3 test failures. Attached.
> These are the same failures that you reported on centos.

Indeed.

> 10 s is so long, i suspect there is a deadlock.

Possibly. Often the cause of a deadlock, in interprocess communication,
is that a file descriptor which was meant to be left open in 1 process
only is actually open in 2 or more processes.

> Can you please tell us how to reproduce (either sun or centos)? Where
> do you get your vm image, how you run it, any specific env settings,
> which compiler, any other important details?

Sure.

=== CentOS 8 stream installation =

Use CentOS 8 stream 2022-10-05 from
https://ftp.gwdg.de/pub/linux/centos/8-stream/isos/x86_64/

RAM size: 1.0 GiB
CPUs: 1
Disk size: 15 GB.

The installation menu is in a stupid order: Can only enable NTP servers
after networking is enabled! Therefore do things in this order:

Installation Destination:
Storage Configuration: Custom
Standard Partition  14 GiB (14336 MiB)  /  ext4
Standard Partition  1  GiB (1024 MiB)   swap

KDump:
Disable kdump.

Network & host name:
Enable networking.
Ethernet config: General > Enable "Connect automatically".
Host name: centos8s

Time & Date:
Set time zone.
Disable then Enable "Network Time".

Installation Source:
On the network, https://ftp.gwdg.de/pub/linux/centos/8-stream/BaseOS/x86_64/os/
URL type: repository URL
Deselect AppStream.
Select AppStream.

Software selection:
  Base Environment: Workstation
  Add-ons: Development Tools, Graphical Administration Tools

Root password:
  login: root
  password: **
  Press "Done" twice.

User settings:
  login: bruno
  password: **
  Select "Make this user administrator".
  Press "Done".

Click "Begin installation".

Wait for the installation to complete.

Power off. Eject CD.

Welcome wizard:
  Privacy: Location services: off.

Popup menu > Settings > Privacy > Screen Lock
Automatic screen lock = Off

Popup menu > Settings > Power > Power Saving
Blank screen = Never

Activities > Software > Updates: Refresh. -> Up to date.

Activities > Software

Search: GNU Emacs, install
Search: gVim, install

$ dnf list
# Not needed:
#$ sudo dnf install make
#$ sudo dnf install gcc
#$ sudo dnf install gcc-c++

Power Off.

=== CentOS 8 stream build configuration ==

CC="gcc"; CXX="g++"; export CC CXX

../configure --prefix=$HOME/inst-x86_64-64 \
 CPPFLAGS="-I$HOME/inst-x86_64-64/include -Wall" \
 LDFLAGS="-L$HOME/inst-x86_64-64/lib" 2>&1 | tee log1 \
&& make 2>&1 | tee log2 \
&& make check 2>&1 | tee log3

=== Solaris 11 OmniOS installation =

OmniOS, a distro based on Illumos - roughly Solaris 11 compatible.

Download OmniOS release 2020-11-02 from
https://downloads.omniosce.org/media/stable/omniosce-r151036.iso

RAM size: 1.5 GiB
CPUs: 1
Disk size: 10 GB

Host name: omnios
Time zone: Europe / Germany / Germany
Configure:
  Networking:
Configuration mode: DHCP
  User:
Login: bruno
Password: **
Grant both administrator and sudo role
  Root password: **
Reboot

Eject CD/DVD. Reboot.

https://omniosce.org/info/getstarted.html

# pkg refresh
# pkg list -u
# pkg update
# pkg install pkg:/package/pkg
# pkg update

Reboot.

Package repositories:
https://omniosce.org/info/ipsrepos.html
-> https://pkg.omniosce.org/r151036/core/en/catalog.shtml
-> https://pkg.omniosce.org/r151036/extra/en/catalog.shtml

# pkg search /usr/bin/gcc
# pkg search /usr/bin/g++
# pkg search /usr/include/stdio.h
# pkg search /usr/bin/gdb   # none, use mdb instead
# pkg search /usr/bin/emacs # none, use vi = vim instead

# pkg install /developer/gcc9
# pkg install /system/header
# pkg install /developer/build/gnu-make

=== Solaris 11 OmniOS build configuration =

CC="gcc -O2"; CXX="g++ -O2"; export CC CXX
CONFIG_SHELL=/usr/bin/bash; export CONFIG_SHELL

../configure --prefix=$HOME/prefix64 \
 CPPFLAGS="-I$HOME/prefix64/include -Wall" \
 LDFLAGS="-L$HOME/prefix64/lib" 2>&1 | tee log1 \
&& gmake 2>&1 | tee log2 \
&& gmake check 2>&1 | tee log3

=

Re: GNU Make 4.3.92 on OpenBSD 6.5

[Bruno Haible]

On OpenBSD 6.5, I see 6 test failures.



makeerror-x86_64-unknown-openbsd6.5.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on Cygwin

[Bruno Haible]

I wrote:
> On Cygwin 2.9.0 (64-bit), compilation works fine, but there are 11 test
> failures.

With GNU make 4.3.92, we're down to 10 test failures.



makeerror-x86_64-pc-cygwin2.9.0.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on mingw

[Bruno Haible]

I wrote:
> On mingw (on Windows 10 in a Cygwin dev environment), compilation works
> fine, but there are 91 test failures.

With GNU make 4.3.92, this is down to 75 test failures.



makeerror-x86_64-w64-mingw.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on GNU/Hurd

[Bruno Haible]

Paul Smith wrote:
> On Wed, 2022-10-19 at 03:14 +0200, Bruno Haible wrote:
> > PATH_MAX does not exist on GNU/Hurd (intentionally, because file
> > names are of arbitrary length).
> 
> Thanks, I've fixed this by setting a large value (4096) as PATH_MAX if
> it's not set anywhere.

Thanks. With GNU make 4.3.92, the compilation now succeeds, but there are
9 test failures.



makeerror-i686-unknown-hurd.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on Solaris 11

[Bruno Haible]

I wrote:
> On Solaris 11.4 / x86_64, in 64-bit mode, the compilation works fine, but 
> there
> are 20 test failures. Likewise in 32-bit mode.
> 
> On Solaris 11 OmniOS, in 64-bit mode, the compilation works fine, but there
> are 22 test failures. In 32-bit mode, even 26 test failures.
> 
> On Solaris 11 OpenIndiana, in 64-bit mode, the compilation works fine, but 
> there
> are 20 test failures. In 32-bit mode, even 24 test failures.

With GNU make 4.3.92, the results are much better:
  - On Solaris 11.4 and Solaris 11 OpenIndiana, all tests pass.
  - On Solaris 11 OmniOS, there are only 3 test failures. Attached.



makeerror-x86_64-pc-solaris2.11-omnios.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on FreeBSD

[Bruno Haible]

I wrote:
> On FreeBSD 11 / x86, the compilation works fine but 1 test fails.

On the same machine, with GNU make 4.3.92, all tests pass.

Re: GNU make 4.3.92 on openSUSE Leap 15.2

[Bruno Haible]

I wrote:
> On OpenSUSE Leap 15.2 / x86_64 (a glibc 2.26 system), the compilation works 
> fine
> but 3 tests fail.

On the same system, with GNU make 4.3.92, I see only 1 test failure: the
wildcard tests. Due to the older glibc.



makeerror-x86_64-pc-linux-gnu-opensuse15.2.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on Manjaro 17 — bi-arch problem

[Bruno Haible]

Paul Smith wrote:
> > The cause:
> > libguile-2.2.so happens to be installed only as 64-bit binaries, in
> > /usr/lib.
> > Not as 32-bit binaries, in /usr/lib32. Yet, /usr/include/guile/2.2/
> > exists.
> 
> I added extra configure checking to try to link with Guile, not just
> assume that if we can find the header we're good to go.

Unfortunately, it did not fix the problem. Find attached the details
of that failed build.



makeerror-manjaro17-32bit.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on Manjaro 17

[Bruno Haible]

I wrote:
> On Manjaro Linux 17 (a glibc 2.28 system) in 64-bit mode, the compilation
> works fine, but there are 2 test failures.

With GNU make 4.3.92, all tests pass.

Re: GNU make 4.3.92 on CentOS 8 Stream

[Bruno Haible]

I wrote:
> On CentOS 8 Stream / x86_64 (a glibc 2.28 system), the compilation works fine,
> but the test suite has failures in the 'output-sync' category:
> - 3 failures in a build with gcc

The same 3 failures still occur with GNU make 4.3.92.




makeerror-x86_64-pc-linux-gnu-centos-8-stream.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.92 on Debian 11.1

[Bruno Haible]

I wrote:
> On Debian 11.1 / x86_64 (a glibc 2.31 system) compilation succeeds
> but there are 2 test failures.

With GNU make 4.3.92, I see all tests pass.

Re: GNU make 4.3.92 on Debian 9.1

[Bruno Haible]

Martin Dorey wrote:
> I looked into it further and concluded that failure is indeed expected on 
> Debian 9, where it's a harmless documentation of the legacy $(wildcard) 
> behavior with dangling symlinks there.

GNU make 4.3.92, on the same machine, shows only this one failure:
functions/wildcard .. FAILED (9/10 passed)



makeerror-i686-pc-linux-gnu-debian9.1.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.91 on Debian 9.1

[Bruno Haible]

Paul Smith wrote:
>   *** Testing failed!  Details saved in: makeerror-x86_64-pc-linux-gnu.tar.gz
>   *** Please report to 
> 
>   make[3]: *** [Makefile:1537: check-regression] Error 1
>   make[2]: *** [Makefile:1271: check-am] Error 2
>   make[1]: *** [Makefile:973: check-recursive] Error 1
>   make: *** [Makefile:1192: distcheck] Error 1
> 
> The tar file is named with the host triplet, and all the things I might
> want (hopefully!!) are there.  It exists in the working directory.

Thank you! That should make the next reports by Nelson and me much more useful
to you.

Bruno

Re: GNU make 4.3.91 on CentOS 8 Stream

[Bruno Haible]

Paul Smith wrote:
> I bumped the timeout to 10 seconds because, why not?  I'll be
> interested to see if we still get these timeouts...

Yes, with tmout changed from 4 to 10 in tests/thelp.pl, I still
see these failures among the output-sync tests. On a machine with
minimal load.

Bruno

Re: GNU make 4.3.91 on Cygwin

[Bruno Haible]

Paul Smith wrote:
> > > On Cygwin 2.9.0 (64-bit), compilation works fine, but there are 11
> > > test failures.
> 
> Is it feasible to run these tests, particularly the Windows ones, on
> the GNU make 4.3 release package?

Sure. Find attached the results for GNU make 4.3 on the same Cygwin:
2 failures
  work/features/exec.diff
  work/options/dash-l.diff

> I'd just like to make sure I didn't
> make things significantly worse there.

In 4.3.91 I saw 11 failures:
  work/features/exec.diff
  work/features/jobserver.diff
  work/features/jobserver.diff.1
  work/features/jobserver.diff.11
  work/features/jobserver.diff.2
  work/features/jobserver.diff.6
  work/features/parallelism.diff.12
  work/features/parallelism.diff.4
  work/features/recursion.diff
  work/functions/shell.diff.20
  work/misc/general4.diff.9

> I could remove the
> MinGW shutils from my PATH and get the suite working without them but I
> don't want to undertake that for this release.

For the Cygwin port, this wouldn't help.

For the mingw port, it sounds like Eli already has some patches (or at least
he knows which places need to be patched) [1].

Bruno

[1] https://lists.gnu.org/archive/html/bug-make/2022-10/msg00168.html


cygwin-make4.3-failures.tar.gz
Description: application/compressed-tar

[bug #52018] suggestion: test case for glob with dangling symlink

[Bruno Haible]

Follow-up Comment #7, bug #52018 (project make):

> So Debian Stretch aka 9, with glibc 2.24, fails, where Debian Buster aka 10,
with glibc 2.28, passes, meaning that it exhibits the new behavior, where
$(wildcard) matches even dangling symlinks.

It would be possible for 'make' to not have this test failure, that is, to
exhibit the new behaviour of $(wildcard) even on older glibc systems. The way
to do so would be to use the Gnulib module 'glob', which is documented to fix
this problem: https://www.gnu.org/software/gnulib/manual/html_node/glob.html

Currently GNU make uses only part of the Gnulib module 'glob': It has the .c
file, but uses a module 'make-glob' instead of 'glob'. On Debian 9.1, this
module produces:
- during configuration the message "checking if system libc has GNU glob...
yes"
- in config.status the substitution USE_SYSTEM_GLOB ← yes.

That's why we see this test fail on glibc < 2.27 (and likely also AIX 7.2,
Solaris 11.4) systems.

But it's not all so simple to use full Gnulib modules in GNU make, see
gl/README...


___

Reply to this item at:

  

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

Re: GNU make 4.3.91 on Debian 9.1

[Bruno Haible]

Hi Paul,

> For example, for the failures that appear to be
> timeouts sometimes the test suite will generate some information about
> that, to stdout/stderr.
> 
> Maybe there's some make target or script that, if it exists, the
> platform testing scripts will run on failure to generate the tar file?

Some testers (like Nelson Beebe) have more evolved "platform testing scripts"
than others. I use some "platform testing routine", that involves looking at
the "make check" output and guess what info would be useful to send back.

> With an error I'd like to get various other files such as the
> src/config.h file, the config.status file if it exists, plus the
> test/work directory and also the output of the configure/build/test
> run.

It would be useful to formalize this, so that the platform testers' feedback
becomes more useful to you. For example, Nelson's summary today [1] shows
that he thought it would be useful to report the part of the "make check"
output that contains the failures. I thought — seeing the line
  3 Tests in 3 Categories Failed (See .diff* files in work dir for details)
— that it would be good to do
cd tests; tar cvfz $platform-failures.tar.gz `find work -name '*.diff*'`
and send that. It turns out that both are insufficient for your analysis.
If you tell us what to return as part of the feedback, we can accommodate it.

Many GNU packages create a 'test-suite.log' file, that contains the list of
failed or skipped tests, plus the log file (stdout+stderr) for each. This
makes it simple: As a tester, I simply attach this test-suite.log (or the
parts I judge relevant).

> the config.status file if it exists

Yes, the config.status file is useful to attach, especially when the
compilation failed, but probably also when the compilation succeeded and
some tests failed.

> the src/config.h file

The src/config.h is redundant IMO, since it is derived from config.status.

> plus the test/work directory

All of it? Or a selected part of it?

> and also the output of the configure/build/test run.

Nelson and I do keep these outputs, as part of our build scripts. If you
want it, we can send it. We only need to know what to send.

> I'm happy to add something to GNU make to collect "useful stuff" if
> there's a standard way that testers would like it.
> 
> Maybe just augmenting the check target to do more?

Yes. Instead of printing
  See .diff* files in work dir for details
it could
  - generate a summary file with details (like test-suite.log, described
above), and/or
  - generate tarball with useful info to send, and/or
  - (if you prefer receiving mails with several attachments instead of a
tarball attachment) print a list of files to send.
And ideally, also print the email address for the reports. I sent my reports
to bug-make@; Nelson sent his to platform-testers@.

Assuming what you want is a tarball with
  config.status
  `find tests/work -name '*.diff*'`
  `find tests/work -name '*.diff*' | sed -e 's/\.diff/.log/'`
that's what I'm sending now.

Bruno

[1] https://lists.gnu.org/archive/html/platform-testers/2022-10/msg5.html


debian91-failures.tar.gz
Description: application/compressed-tar

Re: GNU make 4.3.91 on CentOS 8 Stream

[Bruno Haible]

Dmitry Goncharov wrote:
> > On CentOS 8 Stream / x86_64 (a glibc 2.28 system), the compilation works 
> > fine,
> > but the test suite has failures in the 'output-sync' category:
> > - 3 failures in a build with gcc,
> > - 4 failures in a build with clang-15.0.2.
> 
> 
> I saw a similar test timeout.

If the test hit a timeout, the timeout is definitely too small.

> On that occasion the machine was heavily
> loaded, so i thought make did not have a chance to run in that time
> frame.  In your case was the test running on some loaded machine or a
> poor virtual machine?

It's in a VM, but in a fast one, due to good hardware. In the VM, I had
only "make check" running. The load of the entire system was about 2.5
when I had 6 VMs open simultaneously, on a CPU with 8 cores.
All VMs configured to use nested paging, and so on.
In the 'make-4.3.91' directory:
  time ./configure  7.4 sec
  time make 5.6 sec

Bruno

GNU make 4.3.91 on other platforms

[Bruno Haible]

On some platforms, the compilation works fine and all tests pass:
- Ubuntu / x86_64 22.04
- macOS 10.13
- NetBSD 9

Bruno

GNU make 4.3.91 on GNU/Hurd

[Bruno Haible]

On GNU/Hurd (from 2022), there is one compilation error:

depbase=`echo src/arscan.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc-12 -DHAVE_CONFIG_H   -Isrc -I../src -Ilib -I../lib 
-DLIBDIR=\"/home/bruno/lib\" -DLOCALEDIR=\"/home/bruno/share/locale\" 
-DINCLUDEDIR=\"/home/bruno/include\"  -I/home/bruno/include -Wall  -g -O2 -MT 
src/arscan.o -MD -MP -MF $depbase.Tpo -c -o src/arscan.o ../src/arscan.c &&\
mv -f $depbase.Tpo $depbase.Po
In file included from ../src/makeint.h:151,
 from ../src/arscan.c:17:
../src/arscan.c: In function 'ar_scan':
../src/arscan.c:729:60: error: 'PATH_MAX' undeclared (first use in this 
function); did you mean 'PATH_VAR'?
  729 |   if (err || name_len == 0 || name_len >= MIN (PATH_MAX, 
INT_MAX))
  |^~~~
../src/arscan.c:729:60: note: each undeclared identifier is reported only once 
for each function it appears in
make[1]: *** [Makefile:885: src/arscan.o] Error 1

PATH_MAX does not exist on GNU/Hurd (intentionally, because file names are
of arbitrary length).

Bruno

GNU make 4.3.91 on mingw

[Bruno Haible]

On mingw (on Windows 10 in a Cygwin dev environment), compilation works
fine, but there are 91 test failures.



mingw-failures.tar.gz
Description: application/compressed-tar

GNU make 4.3.91 on Cygwin

[Bruno Haible]

On Cygwin 2.9.0 (64-bit), compilation works fine, but there are 11 test
failures.



cygwin-failures.tar.gz
Description: application/compressed-tar

GNU make 4.3.91 on Solaris 11

[Bruno Haible]

On Solaris 11.4 / x86_64, in 64-bit mode, the compilation works fine, but there
are 20 test failures. Likewise in 32-bit mode.

On Solaris 11 OmniOS, in 64-bit mode, the compilation works fine, but there
are 22 test failures. In 32-bit mode, even 26 test failures.

On Solaris 11 OpenIndiana, in 64-bit mode, the compilation works fine, but there
are 20 test failures. In 32-bit mode, even 24 test failures.



solaris114-failures.tar.gz
Description: application/compressed-tar


omnios-failures.tar.gz
Description: application/compressed-tar


openindiana-failures.tar.gz
Description: application/compressed-tar

GNU make 4.3.91 on FreeBSD

[Bruno Haible]

On FreeBSD 11 / x86, the compilation works fine but 1 test fails.



freebsd11-failures.tar.gz
Description: application/compressed-tar

GNU make 4.3.91 on openSUSE Leap 15.2

[Bruno Haible]

On OpenSUSE Leap 15.2 / x86_64 (a glibc 2.26 system), the compilation works fine
but 3 tests fail.



opensuse152-failures.tar.gz
Description: application/compressed-tar

GNU make 4.3.91 on Manjaro 17 — bi-arch problem

[Bruno Haible]

On Manjaro Linux 17, installed from manjaro-kde-17.1.12-stable-x86_64.iso,
it is possible to build 64-bit binaries (with CC="gcc") or 32-bit binaries
(with CC="gcc -m32").

With CC="gcc -32", the compilation fails:

$ make
...
gcc -m32 -I/usr/include/guile/2.2 -pthread  -g -O2 -Wl,--export-dynamic 
-L/home/bruno/prefix32/lib -o make 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/posixos.o  src/remote-stub.o  -lguile-2.2 -lgc  
lib/libgnu.a   -ldl 
/bin/ld: skipping incompatible 
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../libguile-2.2.so when searching 
for -lguile-2.2
/bin/ld: skipping incompatible /usr/lib/libguile-2.2.so when searching for 
-lguile-2.2
/bin/ld: cannot find -lguile-2.2
/bin/ld: skipping incompatible 
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../libgc.so when searching for -lgc
/bin/ld: skipping incompatible /usr/lib/libgc.so when searching for -lgc
/bin/ld: cannot find -lgc
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:821: make] Error 1

The cause:
libguile-2.2.so happens to be installed only as 64-bit binaries, in /usr/lib.
Not as 32-bit binaries, in /usr/lib32. Yet, /usr/include/guile/2.2/ exists.

The configuration has produced incorrect results:
...
checking for GNU Guile... 2.2
checking for GUILE... yes
checking for libguile.h... yes
...
The first two among these findings are wrong, since /usr/lib32/libguile.* does
not exist.

$ grep GUILE config.status
S["HAVE_GUILE_FALSE"]="#"
S["HAVE_GUILE_TRUE"]=""
S["GUILE_LIBS"]="-lguile-2.2 -lgc "
S["GUILE_CFLAGS"]="-I/usr/include/guile/2.2 -pthread "
D["HAVE_GUILE"]=" 1"

These five values are all wrong.

Bruno

GNU make 4.3.91 on Manjaro 17

[Bruno Haible]

On Manjaro Linux 17 (a glibc 2.28 system) in 64-bit mode, the compilation
works fine, but there are 2 test failures.



manjaro17-failures.tar.gz
Description: application/compressed-tar

GNU make 4.3.91 on CentOS 8 Stream

[Bruno Haible]

On CentOS 8 Stream / x86_64 (a glibc 2.28 system), the compilation works fine,
but the test suite has failures in the 'output-sync' category:
- 3 failures in a build with gcc,
- 4 failures in a build with clang-15.0.2.



centos8s-gcc-failures.tar.gz
Description: application/compressed-tar


centos8s-clang-failures.tar.gz
Description: application/compressed-tar

GNU make 4.3.91 on Debian 11.1

[Bruno Haible]

On Debian 11.1 / x86_64 (a glibc 2.31 system) compilation succeeds
but there are 2 test failures.



debian111-failures.tar.gz
Description: application/compressed-tar

GNU make 4.3.91 on Debian 9.1

[Bruno Haible]

On Debian 9.1.0 / x86 (a machine with glibc 2.24), the compilation succeeds
but 3 tests fail.



debian91-failures.tar.gz
Description: application/compressed-tar

Re: Missing [/usr/local]/var/lib and [/usr/local]/tmp

[Bruno Haible]

Jeffrey Walton wrote:
> I believe MacOS maps /etc and /tmp to a private area for the user.
> They are not world readable/writable. I believe Apple did it for
> hardening.
> 
> Here's from a MacOS X 10.5 machine I have:
> 
> $ ls -l /etc /tmp
> lrwxr-xr-x@ 1 root  wheel  11 Feb 10  2015 /etc -> private/etc
> lrwxr-xr-x@ 1 root  wheel  11 Feb 10  2015 /tmp -> private/tmp

/tmp is world-writable, of course:

$ ls -lLd /etc /tmp
drwxr-xr-x@ 124 root  wheel  3968 27 Jun 01:25 /etc
drwxrwxrwt@   8 root  wheel   256 18 Jul 14:38 /tmp

Bruno

Re: Missing [/usr/local]/var/lib and [/usr/local]/tmp

[Bruno Haible]

Alejandro Colomar wrote:
> I used the following:
> 
> tmpdir := $(prefix)/tmp

Writing it like this has two drawbacks:
  1) The user cannot force a specific temporary directory by setting
 the TMPDIR environment variable. This may be blocking if the
 default temporary directory has not enough room.
  2) It creates one more directory that requires either regular attention
 (so that it does not fill up over time) or a fascist policy of the
 kind "let's remove the contents of this directory regularly".

Suggestion: Use ${TMPDIR-/tmp} instead.

See also [1].

Bruno

[1] 
https://superuser.com/questions/332610/where-is-the-temporary-directory-in-linux

Re: "make -jN" requires mechanical changes to a Makefile [SOLVED]

[Bruno Haible]

Henrik Carlqvist wrote:
> 2) Don't mention some of the extra targets:
> ===
> all : copy1
>  
> copy1: Makefile
>   install -c -m 644 Makefile copy1
>   install -c -m 644 Makefile copy2
>   install -c -m 644 Makefile copy3
>   install -c -m 644 Makefile copy4
> ===

Fails (D) and (E). => Not a solution to the problem.

Bruno

Re: "make -jN" requires mechanical changes to a Makefile [SOLVED]

[Bruno Haible]

Hi Paul,

> There is a straightforward and portable way to do this even with
> traditional make, it's just not as nice (but, nicer than changing all
> the recipes to use test IMO! :)).
> 
> If you have a rule like this:
> 
> ... : 
>   
> 
> where  generates all targets with one invocation, then your
> best bet is to modify this rule into two rules:
> 
> ... : .sentinel ;
> 
>   .sentinel: 
>   
>   @touch $@
> 
> Note, it's critical to include the semicolon here.  Or if you prefer to
> be more explicit you can write something like:
> 
> ... : .sentinel
>   : do nothing
> 
> This will work properly.

Thanks for showing this idiom.

I think this can be improved a bit: Instead of 'touch .sentinel' I would
use 'echo > .sentinel'. Because if you use 'touch .sentinel' and the build
directory is on an NFS mount and the clock of the NFS server is ahead the
clock of localhost (I have seen this quite frequently), the timestamp of
.sentinel will be behind the timestamp of the newest , and thus
another "make" run will execute the rule again.

Still, I don't like these '.sentinel' or stamp files, because they
add complexity:
  * The developer has to decide whether the stamp file should go into
the build dir or $(srcdir). The general rule should be that if
 uses only build tools that are guaranteed to be present,
then   ... and the stamp file should go into the build dir,
whereas if they use less common tools (e.g. bison), they should
all go into $(srcdir).
  * The automake dist target needs to be adjusted to include this stamp
file.
  * Version control (.gitignore) needs to be adjusted to include this
stamp file.

I'll use the rule with a phony target and 'test ... -ot ...', unless you
find a problem with it (other than the potential portability problem
redarding 'test').

Bruno

Re: "make -jN" requires mechanical changes to a Makefile [SOLVED]

[Bruno Haible]

> ===
> all : copy1 copy2 copy3 copy4
> 
> copy1: Makefile
>   { test -f copy1 && test ! copy1 -ot Makefile; } || { rm -f copy4; 
> $(MAKE) copies; }
> copy2: copy1
>   { test -f copy2 && test ! copy2 -ot copy1; } || { rm -f copy4; $(MAKE) 
> copies; }
> copy3: copy2
>   { test -f copy3 && test ! copy3 -ot copy2; } || { rm -f copy4; $(MAKE) 
> copies; }
> copy4: copy3
>   { test -f copy4 && test ! copy4 -ot copy3; } || { rm -f copy4; $(MAKE) 
> copies; }
> 
> copies:
>   install -c -m 644 Makefile copy1
>   install -c -m 644 Makefile copy2
>   install -c -m 644 Makefile copy3
>   install -c -m 644 Makefile copy4
> .PHONY: copies
> ===
> 
> This solution fulfils all the requirements.

It can be simplified a bit. And remove verbosity:

===
all : copy1 copy2 copy3 copy4

copy1: Makefile
@{ test -f copy1 && test ! copy1 -ot Makefile; } || $(MAKE) copies
copy2: copy1
@{ test -f copy2 && test ! copy2 -ot copy1; } || $(MAKE) copies
copy3: copy2
@{ test -f copy3 && test ! copy3 -ot copy2; } || $(MAKE) copies
copy4: copy3
@{ test -f copy4 && test ! copy4 -ot copy3; } || $(MAKE) copies

copies:
install -c -m 644 Makefile copy1
install -c -m 644 Makefile copy2
install -c -m 644 Makefile copy3
install -c -m 644 Makefile copy4
.PHONY: copies
===

Re: "make -jN" requires mechanical changes to a Makefile [SOLVED]

[Bruno Haible]

Continuing this thread from May 2019
:
The problem was:

  How can a rule that generates multiple files be formulated so
  that it works with parallel make?

For example, a rule that invokes bison, or a rule that invokes
a different Makefile. For simplicity, here, use a rule that
creates 4 files copy1, copy2, copy3, copy4.

===
all : copy1 copy2 copy3 copy4

copy1 copy2 copy3 copy4: Makefile
install -c -m 644 Makefile copy1
install -c -m 644 Makefile copy2
install -c -m 644 Makefile copy3
install -c -m 644 Makefile copy4
===

Unfortunately, with "make -j8", it invokes the rule multiple times.

It is possible to change this Makefile so that
  (A) "rm -f copy?; make" executes the rule once.
  (B) "rm -f copy?; make -j8" executes the rule once as well.
  (C) After "make", another "make" just prints "Nothing to be done for 'all'."
  (D) After removing one of the files copy?, "make" executes the rule once.
  (This covers also the case of pressing Ctrl-C during "make", then
  doing "make" again.)
  (E) After replacing one of the files copy? with a file that is older than
  Makefile, "make" executes the rule once.

There are three possibilities:


(I) Assuming GNU make >= 4.3, the "Grouped explicit target" syntax does it.
Thanks to Kaz Kylheku and Paul Smith for having added this.

===
all : copy1 copy2 copy3 copy4

copy1 copy2 copy3 copy4 &: Makefile
install -c -m 644 Makefile copy1
install -c -m 644 Makefile copy2
install -c -m 644 Makefile copy3
install -c -m 644 Makefile copy4
===

But it will take a number of years until we can assume that all 'make'
programs that we care about support this syntax.


(II) It is possible to turn off parallel make. This does it:

===
all : copy1 copy2 copy3 copy4

copy1 copy2 copy3 copy4 : Makefile
install -c -m 644 Makefile copy1
install -c -m 644 Makefile copy2
install -c -m 644 Makefile copy3
install -c -m 644 Makefile copy4

# This Makefile contains rules which don't work with parallel make.
# So, turn off parallel execution in this Makefile.
.NOTPARALLEL:
===

But some people who want to minimize wall-clock execution time of
their builds may not like it.


(III) Use portable make syntax and still allow parallel make.

This is a bit harder. My solution is to first analyze in which order
the rule will generate the various files and thus what the expected
timestamp order is. In this case, it is:
  Makefile <= copy1 <= copy2 <= copy3 <= copy4

First some attempts that don't work:

===
all : copy1 copy2 copy3 copy4

copy1: Makefile
install -c -m 644 Makefile copy1
install -c -m 644 Makefile copy2
install -c -m 644 Makefile copy3
install -c -m 644 Makefile copy4

copy2 copy3 copy4: copy1
===

Fails (E).

===
all : copy1 copy2 copy3 copy4

copy4: Makefile
install -c -m 644 Makefile copy1
install -c -m 644 Makefile copy2
install -c -m 644 Makefile copy3
install -c -m 644 Makefile copy4

copy1 copy2 copy3: copy4
===

Fails (E) as well.

===
all : copy1 copy2 copy3 copy4

copy4: Makefile
install -c -m 644 Makefile copy1
install -c -m 644 Makefile copy2
install -c -m 644 Makefile copy3
install -c -m 644 Makefile copy4

copy1: copy4
test -f copy1 || { rm -f copy4; $(MAKE) copy4; }
copy2: copy4
test -f copy2 || { rm -f copy4; $(MAKE) copy4; }
copy3: copy4
test -f copy3 || { rm -f copy4; $(MAKE) copy4; }
===

Fails (E) for copy1, ..., copy3.
And fails (C), i.e. clutters the "make" output.

===
all : copy1 copy2 copy3 copy4

copy1: Makefile
{ test -f copy1 && test ! copy1 -ot Makefile; } || { rm -f copy4; 
$(MAKE) copies; }
copy2: copy1
{ test -f copy2 && test ! copy2 -ot copy1; } || { rm -f copy4; $(MAKE) 
copies; }
copy3: copy2
{ test -f copy3 && test ! copy3 -ot copy2; } || { rm -f copy4; $(MAKE) 
copies; }
copy4: copy3
{ test -f copy4 && test ! copy4 -ot copy3; } || { rm -f copy4; $(MAKE) 
copies; }

copies:
install -c -m 644 Makefile copy1
install -c -m 644 Makefile copy2
install -c -m 644 Makefile copy3
install -c -m 644 Makefile copy4
.PHONY: copies
===

This solution fulfils all the requirements.

Can we use 'test FILE1 -ot FILE2'?
- POSIX 'test' does not support this option.
 

Re: make-4.3: wildcard test #9 fails

[Bruno Haible]

Hi Paul,

> > Building GNU make 4.3 on Ubuntu 16.04, produces one failing test:
> 
> This is because the glob() function in the older GNU libc has a bug
> related to handling symlinks correctly.

Gnulib provides a workaround against this bug in its 'glob' module [1].
But GNU make ships a copy of glob.c from 1999 :-(

Bruno

[1] https://www.gnu.org/software/gnulib/manual/html_node/glob.html

make-4.3: wildcard test #9 fails

[Bruno Haible]

Hi,

Building GNU make 4.3 on Ubuntu 16.04, produces one failing test:

$ ./configure --prefix=/arch/x86_64-linux-gnu/gnu-inst-make/4.3
$ make
$ make check
...
functions/wildcard .. FAILED (9/10 passed)
...
vms/library . N/A

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

Makefile:1998: die Regel für Ziel „check-regression“ scheiterte
make[2]: *** [check-regression] Fehler 1

$ cat tests/work/functions/wildcard.diff.9
*** work/functions/wildcard.base.9  Sun Apr  5 15:16:18 2020
--- work/functions/wildcard.log.9   Sun Apr  5 15:16:18 2020
***
*** 1 
! __ldir
--- 1 
! 

This is on an ext4 file system.
It's not locale dependent: the same result occurs with 'LC_ALL=C make check'.

Additional data:

$ nm make | grep wildcard
0040f820 t func_wildcard
$ nm make | grep glob
00408620 T ar_glob
00408280 t ar_glob_match
0040b220 T dir_setup_glob
00408210 t __do_global_dtors_aux
00632e08 t __do_global_dtors_aux_fini_array_entry
00634560 b global_dl.6802
006341d0 d global_setlist
00637080 b global_variable_set
 U globfree@@GLIBC_2.2.5
 U glob@@GLIBC_2.2.5
00424760 T init_hash_global_variable_set

Bruno

Re: "make -jN" requires mechanical changes to a Makefile

[Bruno Haible]

Howard Chu wrote:
> >> Example with one rule creating 4 files:
> >>
> >> all : copy1 
> >>
> >> copy1: Makefile
> >> install -c -m 644 Makefile copy1
> >> install -c -m 644 Makefile copy2
> >> install -c -m 644 Makefile copy3
> >> install -c -m 644 Makefile copy4
> > 
> > I think the "representative" file should be copy4 here, because it's the one
> > that gets created last.
> 
> That sort of thing is only true in serial make, you can't rely on it in 
> parallel make.

The sequence of lines of the recipe of a rule gets executed in order,
even in parallel make, no?

Bruno


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: "make -jN" requires mechanical changes to a Makefile

[Bruno Haible]

Henrik Carlqvist wrote:
> Example with one rule creating 4 files:
> 
> all : copy1 
> 
> copy1: Makefile
> install -c -m 644 Makefile copy1
> install -c -m 644 Makefile copy2
> install -c -m 644 Makefile copy3
> install -c -m 644 Makefile copy4

I think the "representative" file should be copy4 here, because it's the one
that gets created last.

Otherwise, when the user interrupts "make" after copy1 was created but before
copy2, copy3, copy4 are created, and then retries "make" again, the second
'make' invocation will fail somewhere when it references copy2...copy4.

Bruno


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: "make -jN" requires mechanical changes to a Makefile

[Bruno Haible]

Hi Paul,

> > The real workaround goes like this:
> > 
> > ===
> > all : copy1 copy2 copy3 copy4
> > 
> > copy1: Makefile
> > install -c -m 644 Makefile copy1
> > install -c -m 644 Makefile copy2
> > install -c -m 644 Makefile copy3
> > install -c -m 644 Makefile copy4
> > copy2 copy3 copy4: copy1
> > ===
> 
> This is not fully-correct either:
> 
>   $ make
>   install -c -m 644 Makefile copy1
>   install -c -m 644 Makefile copy2
>   install -c -m 644 Makefile copy3
>   install -c -m 644 Makefile copy4
> 
>   $ rm copy3
> 
>   $ make
>   make: Nothing to be done for 'all'.

Indeed. Thank you for having spotted this; otherwise I would have put a
broken rule into GNU gettext.

Now, when my use-case is:
  - one rule that produces N files (N > 1),
  - I want "make" to execute the rule only once, not N times,
even with parallel make.
What is the solution? The documentation page [1] explicitly does NOT mention
this use-case for multiple targets on the same rule.

You mentioned splitting the rule into one rule per file. But bison does not
work this way; it really produces two files at once. And for other rules
I mentioned Automake limitations.

Parallel make is of growing importance, because Debian now uses parallel builds
by default (quote: "debhelper >= 10 defaults to parallel build").

Bruno

[1] https://www.gnu.org/software/make/manual/html_node/Multiple-Targets.html


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: "make -jN" requires mechanical changes to a Makefile

[Bruno Haible]

Hi,

I wrote:
> The workaround is to introduce an intermediate target:
> 
> ===
> all : copy1 copy2 copy3 copy4
> 
> copy1 copy2 copy3 copy4: install-copies
> .PHONY: install-copies
> install-copies: Makefile
>   install -c -m 644 Makefile copy1
>   install -c -m 644 Makefile copy2
>   install -c -m 644 Makefile copy3
>   install -c -m 644 Makefile copy4
> ===

This workaround doesn't actually work (in the actual case of GNU gettext):
it fails the "make distcheck" verification.

The real workaround goes like this:

===
all : copy1 copy2 copy3 copy4

copy1: Makefile
install -c -m 644 Makefile copy1
install -c -m 644 Makefile copy2
install -c -m 644 Makefile copy3
install -c -m 644 Makefile copy4
copy2 copy3 copy4: copy1
===

Bruno


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: "make -jN" requires mechanical changes to a Makefile

[Bruno Haible]

Henrik Carlqvist wrote:
> If you really prefer to write rules which generates more than one target
> the "right" way to avoid parallel make would be to add the .NOTPARALLEL
> target in the Makefile.

This way allows to turn off parallel make for a single Makefile.
Indeed, this might be a better compromise, when only few Makefiles
have problems with parallel make.

Whereas the snippet I showed turns it off for an entire package (when placed
in the top-level Makefile).

Thanks for the suggestion.

Bruno


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: "make -jN" requires mechanical changes to a Makefile

[Bruno Haible]

Hi Paul,

> This makefile should be written correctly, as:
> 
>   all : copy1 copy2 copy3 copy4
> 
>   copy1: Makefile
>   install -c -m 644 Makefile copy1
>   copy2: Makefile
>   install -c -m 644 Makefile copy2
>   copy3: Makefile
>   install -c -m 644 Makefile copy3
>   copy4: Makefile
>   install -c -m 644 Makefile copy4

The Makefile was simplified. In the real-world case [1], the STATEMENTS
is a recursive invocation of another Makefile, which is generated by
Automake, and for which I cannot create a separate targets
  install-textstyle.h
  install-textstyle_stdbool.h
  install-textstyle_version.h
  install-textstyle_woe32dll.h
(because Automake just does not offer this).

Another real-world example (where a parallel make problem surely
exists, but wasn't reported so far) is this rule from
gettext/gettext-tools/src/Makefile.am:

po-gram-gen.c po-gram-gen.h: po-gram-gen.y
$(AM_V_GEN)$(SHELL) $(YLWRAP) $(srcdir)/po-gram-gen.y \
  y.tab.c po-gram-gen.c \
  y.tab.h po-gram-gen.h \
  y.output po-gram-gen.output \
  -- $(YACC) $(YFLAGS) $(AM_YFLAGS) \
&& sed -e 's|".*/po-gram-gen.y"|"po-gram-gen.y"|' < po-gram-gen.c > 
po-gram-gen.c-tmp \
&& rm -f po-gram-gen.c \
&& mv po-gram-gen.c-tmp $(srcdir)/po-gram-gen.c \
&& { test '$(srcdir)' = . || mv po-gram-gen.h $(srcdir)/po-gram-gen.h; }

It's the same type of problem, and the same mechanical change is needed
for proper support of parallel make.

> I really don't like to try to parse recipes and modify
> behavior depending on what is found.  It leads to a lot of unexpected
> consequences and confusion.

In the current state, supporting parallel make requires extra work
for the maintainer.

Or would you recommend that I add this snippet to the top-level
Makefile of all my projects?

# This package does not support parallel make.
# So, turn off parallel execution (at least in GNU make >= 4.0).
GNUMAKEFLAGS = -j1

Bruno

[1] https://lists.gnu.org/archive/html/bug-gettext/2019-05/msg00084.html


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make