On Wed, Jun 19, 2024 at 06:28:46AM -0700, Larry McVoy wrote:
> On Tue, Jun 18, 2024 at 07:46:15PM -0500, Nevin Liber wrote:
> > But I'll bite.  There was the claim by Larry McVoy that "Writing Makefiles
> > isn't that hard".
> >
> > Please show these beautiful makefiles for a non-toy non-trivial product
>
> Works on *BSD, MacOS, Windows, Linux on a bunch of different architectures,
> Solaris, HPUX, AIX, IRIX, Tru64, etc.

True, but it uses multiple GNU make features, include file inclusions,
conditionals, pattern substitutions, etc.  That probably worked for
Bitkeeper because you controlled the build envirnment for the product,
as you were primarily distributing binaries.

From portability perspective for e2fsprogs, I wanted to make sure I
could build it using the native build environment (e.g., suncc and
later clang, not just gcc, and the default make distributed by Sun,
AIX, Irix, HPUX, and later NetBSD/FreeBSD).  I also wanted to support
shared library support, and I didn't want to deal the horrific
performance attributes of libtool and the inscrutibility of automake.

Since my primary distribution channel was the source tarball (and
later, a git checkout), and other high priority requirement for me is
that I didn't want to require that people need to download some custom
build infratrture.  This rules out cmake, imake, gmake, and blaze
(especially since blaze/bazel requires installing a Java <shudder>
runtime).

And since I did want to use various advanced features (optionally, if
they exist on the system) such as Poix Threads (which back then I
couldn't take for granted as existing on all of the OS's that I
supported) and Thread Local Storage, as opposed to just restricting
myself to the BSD v4.4 feature subset, I needed to use autoconf anyway,
and from a runtime perspective, it only requires m4 / awk / sed which
is available everywhere.

So I did everything using (only) autoconf, including building and
using shared libraries,

with some optional build features that require
GNU make, but the same makefiles will also work on FreeBSD's pmake.  I
do agree with your basic premise, though, which is there's realy no
need to use fancy/complicated build infrastructure such as cmake or
<shudder> imake.

                                                - Ted