Re: Using LS/LE (was: [PATCH v4 2/4] man/man5/tunables.conf: Document system-wide tunables config)

[Ingo Schwarze <schwarze@usta.de>]

Hi Larry,

Larry Kollar wrote on Fri, Aug 28, 2026 at 10:50:50PM -0400:
> Alejandro Colomar <alx@kernel.org> wrote:

>> I believe that a set of makefiles that would handle all of the targets
>> of a project like groff wouldn't take much more than that.  It might be
>> a few hundred kB.  If it's well organized, it can be maintainable.
>> 
>> Because the makefile language is so simple, bugs are easy to spot and
>> fix, compared to autotools (possibly automake, but I can't distinguish
>> them enough).

> I don't know. Can a Makefile check for the presence of certain libraries
> or other apps and fail gracefully

Obviously, a Makefile can do anything a sh(1) script can do -
arguably, the central idea of make(1) is topological sorting
of sh(1) script snippets according to a dependency graph.
So the answer to your question is an emphatic "yes".

> (by which I mean exiting with a message like "You need app X, plus
> libraries Y and Z, installed to successfully compile this.")?

Absolutely, and some real-world Makefiles do just that,
for example the large and frightening bsd.port.mk(5) on OpenBSD:

  https://man.openbsd.org/bsd.port.mk
  https://cvsweb.openbsd.org/ports/infrastructure/mk/bsd.port.mk

But smaller, simpler Makefiles emitting diagnostic messages of the
kind you describe exist, too.

> That's one of the things that "makes" me appreciate taking
> that extra step of typing `.configure` before make.

Well, that doesn't look like a particularly strong argument,
because adding a rule to the Makefile that automatically runs
the configure script when needed would usually not be difficult,
and the end result regarding diagnostics would be identical to
what you desire.

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.

My point isn't that configure should be integrated into the
Makefile.  Quite to the contrary, medium-sized projects like groff
and mandoc that need to run dozens of configuration tests do benefit
from having a separate configure script.  What i'm saying is that
developers can save themselves massive amounts of work and pain
by ditching autoconf(1) and writing their own configure script -
and thus also make life massively easier for their users, because
dealing with autoconf(1) is equally painful for users.

But again, i do *not* advocate for ripping autoconf(1) out of groff
because Branden seems happy enough with it for now, and it kind
of works most of time, admittedly with regular hiccups around
releases.  Ripping it out would look like a make-work project
at this point; constantly revisiting the same decisions is not
very productive, and automake(1) was only integrated a few years ago.

> Now, a lot of older software (or modern, simple programs) won't
> need that complexity, and a well-written INSTALL file can call out
> necessary Makefile edits before letting 'er rip.

Right, suckless.org software comes to mind as an example.
(That's not to say that i would endorse them in every respect -
for example, i like small amounts of configurability and do not
like the "zero configuration at run time" approach of suckless.)

Yours,
  Ingo