Hi Ingo, > Date: 2026-08-29 11:39:20+0200 > From: Ingo Schwarze > [...] > > I think the main reason why build system developers don't usually > run configure automatically from the Makefile is that from a user > perspective, it makes sense to keep the two steps "inspect the > configuration and make some decisions, but do not start building > anything just yet" and "build the stuff, using the variables and > decisions made at the configure stage" separate. Users may even > want to pause between the two steps, consider the decisions made, > for example by inspecting configure output files like config.h > or Makefile.local or, in case serious debugging is needed, config.log > and maybe even change some of the decisions manually and re-run > configure, even though autoconf(1) makes both steps, inspection > and manipulation of decisions, gratuitiously hard, both by spewing > vast amounts of noise and by the ./configure script being next to > unreadable. But saner, better-written configure scripts can make > both inspection and manipulation quite simple and pleasant. > > Running the configure script automatically from the Makefile > would remove this opportunity for inspection and tweaking. In the Linux man-pages, the configure step is done entirely within make(1) --there's no separate ./configure step--. But as you say, a separate configure-only step is important for serious debugging. The solution I implemented is a 'nothing' target in the Makefile, which as the name implies, does nothing. However, it still runs the configuration step, since that runs as part of parsing the makefiles. Here's the rule: nothing:; When I need to debug the build system itself, I run that target; often with special flags for debugging. One common command I use when I need to do this kind of debugging is: $ make -p nothing | less And if I need to see stderr output from the commands used by the configure scripts, here's a common command: $ make HIDE_ERR= nothing I'm not saying that this should be done, but this _can_ be done. With BSD make(1), it might be more difficult to debug, since it doesn't have the -p flag. But the output from configure tests can still be read without building anything, with a dummy 'nothing' rule. Have a lovely day! Alex --