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