Re: configure separate from make or not

[Ingo Schwarze <schwarze@usta.de>]

[trimming Cc:, this starts becoming off-topic on the groff list;
 i'm not subscribed to linux-man@ though]

Hi Alejandro,

Alejandro Colomar wrote on Sat, Aug 29, 2026 at 03:10:25PM +0200:
> From: Ingo Schwarze <schwarze@usta.de>

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

That sounds like a serious abuse of the parsing step to me.
I mean, the whole point of a parsing step is to do parsing and to
build dependency trees, but not to run code.  The purpose of the
execution phase of make(1) then is to run code, in an order determined
from the dependency tree.

> 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

The output of that command looks completely unreadable to me and
is of horrendous size:

   $ gmake -pR nothing | wc
  bash: line 1: gcc: command not found
  realpath: unknown option -- m
  usage: realpath [-q] file
  gmake: warning: undefined variable 'GNUMAKEFLAGS'
   34074  672611 27635924

Over 25 MB of configuration output?  Seriously?


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

It does.  From the OpenBSD make(1) manual:

   -p    Print a dump of the target rules and variables on stdout.  Do not
         build anything.

   -d flags
         Turn on debugging, and specify which portions of make are to
         print debugging information.  flags is one or more of the
         following:

         [only quoting the flags here, without the descriptions,
          for brevity]

         AacdDef g1 g2 hiklmnpqstTv

However, reading the output from a simple configure script is much
simpler than reading make(1) debugging output, for example:
 
   $ ./configure
  file config.log: writing...
  file configure.local: reading...
  tested operating system: OpenBSD -> OSENUM=MANDOC_OS_OPENBSD
  tested cc -W: tested noop: yes
  selected CFLAGS="-g -W -Wall -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wno-unused-parameter"
  tested noop-static: yes
  selected STATIC="-static"
  tested attribute: yes
  tested cmsg: yes
  tested dirent-namlen: yes
  tested be32toh: yes
  tested be32toh-DSYS_ENDIAN: yes
  tested EFTYPE: yes
  tested err: yes
  tested getline: yes
  tested getsubopt: yes
  tested isblank: yes
  tested mkdtemp: yes
  tested mkstemps: yes
  tested nanosleep: yes
  tested ntohl: yes
  tested O_DIRECTORY: yes
  tested PATH_MAX: yes
  tested pledge: yes
  tested sandbox_init: no (compilation failed)
  tested progname: yes
  tested reallocarray: yes
  tested recallocarray: yes
  tested recvmsg: yes
  tested rewb-bsd: yes
  tested rewb-sysv: yes
  tested strcasestr: yes
  tested stringlist: no (compilation failed)
  tested strlcat: yes
  tested strlcpy: yes
  tested strndup: yes
  tested strptime: yes
  tested strsep: yes
  tested strtonum: yes
  tested unveil: yes
  tested vasprintf: yes
  tested fts-DFTS_COMPARE_CONST: no (compilation failed)
  tested fts: yes
  tested less: yes
  selected BINM_PAGER=less
  tested less -T: yes
  selected UTF8_LOCALE=en_US.UTF-8
  tested wchar-DUTF8_LOCALE="en_US.UTF-8": yes
  tested ohash: no (compilation failed)
  tested ohash-lutil: yes
  selected LDADD="   -lutil -lz"
  file config.h: written
  file Makefile.local: written

and then you can inspect config.h and Makefile.local for generated
settings and inspect config.log if serious debugging is needed.

 $ wc config.h Makefile.local config.log
      54     150    1326 config.h
      40     137    1026 Makefile.local
     305    1401   12998 config.log
     399    1688   15350 total

Even the "total" is half a permille of the output volume 
from the gmake -p you recommend - and that already includes *all*
the debugging information, whereas in your 25 MB of gmake -p output,
i was unable to find the reason why the build systems tries to use gcc(1)
even though i don't have GCC installed.  Generally, searching in that
monster is next to impossble because it contains very large numbers
of extremely long lines, each of which contains basically all the
words that one might possibly wish to search for.

> But the output from configure tests can still be read
> without building anything, with a dummy 'nothing' rule.

I briefly tried to read man-pages/GNUmakefile but quickly gave up
because it feels impossible to follow the control flow.
The program fails to explicitly say which targets it runs
with which dependencies, IMHO making it unreadable for a human.

Yours,
  Ingo