Hi Larry, Larry Kollar wrote on Fri, Aug 28, 2026 at 10:50:50PM -0400: > Alejandro Colomar <[email protected]> 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
