Re: GNU make troubleshooting

[Eli Zaretskii]

> From: Bruno Haible 
> Date: Mon, 10 Jul 2023 21:41:24 +0200
> 
> 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?

An approximation to the facts is worse than the facts.

This facility is supposed to show you which files caused a target to
be rebuilt.  Any approximation that doesn't list all of those outdated
files will lose information.

The fact that you saw a long list is a bug that was solved.  Making
Make less capable because of a bug is not wise, IMO.

Re: GNU make troubleshooting

[Eli Zaretskii]

> From: Jeffrey Walton 
> Date: Mon, 10 Jul 2023 16:34:49 -0400
> Cc: bug-make@gnu.org
> 
> I would add GNU's make lacks minimal debug facilities.

I think "make -p" and "make -d" do provide ample debugging
capabilities.

> I think trace is worthless. It does not help the folks writing
> makefiles. Or it has never helped me understand why a statement was
> (or was not) evaluated, or the result of the evaluation.

Then you should be free not to use that option.  I personally think it
does help in some situations.

Re: GNU make troubleshooting

[Jeffrey Walton]

On Mon, Jul 10, 2023 at 4:45 PM Paul Smith  wrote:
>
> [...]
> > That's like peppering a program with printf's. I would like to
> > understand why a statement was (or was not) evaluated, and if
> > evaluated the result, but there is no option with the effect of
> > Bash's 'set +x'.
>
> I think I don't quite understand this.  Basically EVERY line in make is
> always evaluated, unless it's inside an if-statement.  Makefiles are
> not like shell scripts, where you can skip sections or return early
> before some parts are parsed.  The entire makefile is parsed before any
> rules are invoked.

Yes, lots of conditionals and lots of shell'ing, like:

GREP ?= grep
SED ?= sed

ifneq ($(wildcard /usr/xpg4/bin/grep),)
  GREP := /usr/xpg4/bin/grep
endif
ifneq ($(wildcard /usr/xpg4/bin/sed),)
  SED := /usr/xpg4/bin/sed
endif

SUN_COMPILER := $(shell $(CXX) -V 2>&1 | $(GREP) -i -c -E 'CC: (Sun|Studio)')
GCC_COMPILER := $(shell $(CXX) --version 2>/dev/null | $(GREP) -v -E
'(llvm|clang)' | $(GREP) -i -c -E '(gcc|g\+\+)')
XLC_COMPILER := $(shell $(CXX) -qversion 2>/dev/null |$(GREP) -i -c "IBM XL")
CLANG_COMPILER := $(shell $(CXX) --version 2>/dev/null | $(GREP) -i -c
-E '(llvm|clang)')
INTEL_COMPILER := $(shell $(CXX) --version 2>/dev/null | $(GREP) -i -c
'\(icc\)')
...

Jeff

Re: GNU make troubleshooting

[Paul Smith]

On Mon, 2023-07-10 at 16:34 -0400, Jeffrey Walton wrote:
> I would add GNU's make lacks minimal debug facilities.

I assume this is what Bruno means by his point #3: "Single-stepping or
tracing function execution".

> That's like peppering a program with printf's. I would like to
> understand why a statement was (or was not) evaluated, and if
> evaluated the result, but there is no option with the effect of
> Bash's 'set +x'.

I think I don't quite understand this.  Basically EVERY line in make is
always evaluated, unless it's inside an if-statement.  Makefiles are
not like shell scripts, where you can skip sections or return early
before some parts are parsed.  The entire makefile is parsed before any
rules are invoked.

Maybe you can explain more clearly what you want to know.

> I think trace is worthless. It does not help the folks writing
> makefiles. Or it has never helped me understand why a statement was
> (or was not) evaluated, or the result of the evaluation.

That's because that's not its purpose.  It's not trying to help
understand evaluation, it's trying to explain why a given recipe was
run, and which rule was used to run it.

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

[Jeffrey Walton]

On Mon, Jul 10, 2023 at 2:32 PM Bruno Haible  wrote:
>
> 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

I think GNU Make provides all you need for feature testing in C/C++
programs. I don't know about other languages, like Fortran.
I use GNU Make all the time for C/C++ programs in place of Autotools,
CMake and friends.

I would add GNU's make lacks minimal debug facilities. I don't
consider '$(info ...)' debugging. That's like peppering a program with
printf's. I would like to understand why a statement was (or was not)
evaluated, and if evaluated the result, but there is no option with
the effect of Bash's 'set +x'.

I think trace is worthless. It does not help the folks writing
makefiles. Or it has never helped me understand why a statement was
(or was not) evaluated, or the result of the evaluation.

Jeff

Re: GNU make troubleshooting

[Alejandro Colomar]

Hi Bruno, Paul,

On 7/10/23 21:41, Bruno Haible wrote:

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]


My approach to debugging has always been fprintf(3) with C programs, as
I find debuggers too complex for what I need.  When debugging GNU
Makefiles, I have a similar approach, and it usually works.  I need some
intuition to know where to place the statements, but after a few tries,
I usually find the bug.  In GNU Make, the "printf" statement is the
$(info ...) function.  Maybe you didn't know about it?

So, I usually add a few of them before suspicious lines.  It could be:

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

That should solve most of your doubts, doesn't it?

Cheers,
Alex


--

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5



OpenPGP_signature
Description: OpenPGP digital signature

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

[Paul Smith]

On Mon, 2023-07-10 at 21:41 +0200, Bruno Haible wrote:
> > 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?

Well, they're all reading this list so we'll see.

There is already https://remake.readthedocs.io/en/latest/ and the
changes there are quite significant.

The implementation of GNU Make is, unfortunately, not using any sort of
central event handler etc. where you could hook in some kind of user
prompt.  It's a meandering list of individual function calls with
multiple wait points and complex recursion.

Re: GNU make troubleshooting

[Paul Smith]

On Mon, 2023-07-10 at 21:47 +0200, Bruno Haible wrote:
> 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.

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
  gcc -DHAVE_CONFIG_H -I. -I../../gllib -I..  -DGNULIB_STRICT_CHECKING=1 -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

  $ make --version
  GNU Make 4.4.1
  Built for x86_64-pc-linux-gnu
  Copyright (C) 1988-2023 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.

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

[Paul Smith]

On Mon, 2023-07-10 at 21:18 +0200, Bruno Haible wrote:
> 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".

I think your problems with the output were addressed in GNU Make 4.4. 
Anyway I don't see that.

I honestly don't see any point in just printing the "newest"
prerequisite.  If the rule was invoked in the first place then you
already know that _some_ file was newer.  What's the added benefit of
knowing the name of only one, essentially random, prerequisite?

Re: GNU make troubleshooting

[Paul Smith]

On Mon, 2023-07-10 at 21:05 +0200, Bruno Haible wrote:
> $ rm -f mbrtoc32.o
> $ make --trace mbrtoc32.o

If you remove the target then it should only say that it was rebuilt
because the target doesn't exist, regardless of how many other
prerequisite are out of date, because you can't even compute the out of
dateness usefully if there's no target to compare with:

  $ cat Makefile
  all: foo.x bar.x ; @echo hi; touch $@
  %.x: ; touch $@

  $ make
  touch foo.x
  touch bar.x
  hi

  $ make
  make: 'all' is up to date.

  $ rm all

  $ make --trace
  Makefile:1: update target 'all' due to: target does not exist
  echo hi; touch all
  hi

> I'm using GNU make 4.3.

Maybe a version difference.  I'm using 4.4.

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

[Paul Smith]

On Mon, 2023-07-10 at 20:46 +0200, Bruno Haible wrote:
> The " due to: " is useless, since these files
> have not changed since the last compilation. (Suggestion: Reduce this
> list by showing only the file with the newest timestamp. Files with
> older timestamps are redundant.)

I can't explain why you are seeing all these files listed if only a few
of them have changed since the last time the target was updated; that's
not how it works for me:

  $ cat Makefile
  all: foo.x bar.x ; @echo hi; touch $@
  %.x: ; touch $@

  $ make
  touch foo.x
  touch bar.x
  hi

  $ touch bar.x

  $ make --trace
  Makefile:1: update target 'all' due to: bar.x
  echo hi; touch all
  hi

Only shows the newer files not all the files.

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.

Re: [gnu-prog-discuss] Blog Post Sighting: Autotools Considered Harmful

[Paul Smith]

On Mon, 2023-07-10 at 12:56 -0400, Stefan Monnier wrote:
> > There ARE things we could do with GNU Make still that would make it
> > more useful, and faster in some situations, without throwing away
> > the millions of existing makefiles and the knowledgebase.  I
> > maintain a list of them so if this kind of works tickles your
> > fancy, or you have idea of your own and want to discuss them with
> > very knowledgeable people I recommend discussing it on the bug-
> > m...@gnu.org mailing list.
> 
> My main gripe with Make is the absence of good quoting rules, which
> makes it almost impossible to work with files whose names include
> funny characters like spaces or colons.

There was a long thread a number of years ago with an idea I had for
how to handle this.  I wasn't able to really convince people that my
idea would work :).

I was suggesting that there be a new type of "word quoting" in GNU
Make, maybe something like $[some:text here] or something like that. 
The content within that quoting would be omitted from all types of
parsing by the GNU Make parser, including both for special characters
AND for word breaks (that is, the text would be considered a single
word for all word-based functions like filter, foreach, etc. etc.  Of
course we have to decide how to allow "]" (or whatever) in such a
string :-p :-(

The results of $(wildcard ...) or other globbing would automatically be
marked as this type of "atomic word" of course.

This would make it possible to work with difficult filenames, but with
a cost of having to apply this extra markup.  Also based on the
implementation I had in mind, some UTF-8 control characters would no
longer be allowed to appear in makefiles.

Re: GNU make troubleshooting

[Paul Smith]

I want to prefix this by saying that there's no question that make's
traceability could be improved: I'm not saying nothing needs to be
done.

On Mon, 2023-07-10 at 20:32 +0200, Bruno Haible wrote:
> 1) Print the total of the Makefile and all included Makefiles.
>    Like what "gcc -E" does with C code.

This has been requested before, but note that it's not really as useful
as people often think it will be because a lot of the internal database
of make is constructed dynamically, not directly from content in
makefiles.

I find the output of "make -p" helpful as it tells you where every rule
and variable was defined.

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

The "last" one is the one that's referenced in the output.  Finding the
"first" one is not as easy; the error message can be improved here.  In
other similar types of messages we do show both the old and new
locations.

  $ cat Makefile
  all: ;
  all:: ;

  $ make
  Makefile:2: *** target file 'all' has both : and :: entries.  Stop.
   ^ line number if last target

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.


> 2) Where is the Makefile source for each command that gets executed?

Have you tried using the --trace option?  This was added specifically
to provide this kind of information:

  $ cat Makefile
  all: ; @echo hi

  $ make --trace
  Makefile:1: update target 'all' due to: target does not exist
  echo hi
  hi

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

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

No, this has nothing to do with that.

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-prog-discuss] Blog Post Sighting: Autotools Considered Harmful

[Stefan Monnier]

> There ARE things we could do with GNU Make still that would make it
> more useful, and faster in some situations, without throwing away the
> millions of existing makefiles and the knowledgebase.  I maintain a
> list of them so if this kind of works tickles your fancy, or you have
> idea of your own and want to discuss them with very knowledgeable
> people I recommend discussing it on the bug-make@gnu.org mailing list.

My main gripe with Make is the absence of good quoting rules, which
makes it almost impossible to work with files whose names include funny
characters like spaces or colons.


Stefan

[bug #64402] error parsing functions in braces inside ifeq, ifneq

[anonymous]

URL:
  

 Summary: error parsing functions in braces inside ifeq, ifneq
   Group: make
   Submitter: None
   Submitted: Mon 10 Jul 2023 11:40:55 AM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.4
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Mon 10 Jul 2023 11:40:55 AM UTC By: Anonymous
Per the GNU make manual, function call syntax is either
  $(function arguments)  # parenthesis
or
  ${function arguments}  # braces

Using braces in most cases works, however, using braces inside an `ifeq` or
`ifneq` condition sometimes fails with:

*** unterminated call to function 'join': missing '}'.  Stop.

It fails if the function is the 1st argument of the `ifeq`, and the function
has multiple arguments (e.g., findstring). It works if the function is the 2nd
argument of `ifeq`, or the function has only one argument (e.g., sort).
Illustrative examples (more in attached Makefile):

```
#---
ifeq ($(and a),)
endif

# ok
ifeq (${and a},)
endif

# ok
ifneq (,${and a})
endif

# ok
ifneq (${and a},)
endif

# ok
ifneq (,${and a})
endif

#---
ifeq ($(and a, b),)
endif

# Makefile:469: *** unterminated call to function 'and': missing '}'.  Stop.
## ifeq (${and a, b},)
## endif

# ok
ifneq (,${and a, b})
endif

# Makefile:477: *** unterminated call to function 'and': missing '}'.  Stop.
## ifneq (${and a, b},)
## endif

# ok
ifneq (,${and a, b})
endif
```







___
File Attachments:


---
Date: Mon 10 Jul 2023 11:40:55 AM UTC  Name: Makefile  Size: 9KiB   By: None



___

Reply to this item at:

  

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