Re: GNU make troubleshooting

[Jeffrey Walton]

On Mon, Jul 10, 2023 at 2:32 PM Bruno Haible <bruno@clisp.org> 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