[TUHS] Version 256 of systemd boasts '42% less Unix philosophy' The Register

Kevin Bowling kevin.bowling at kev009.com
Thu Jun 20 08:48:29 AEST 2024


On Wed, Jun 19, 2024 at 11:59 PM Theodore Ts'o <tytso at mit.edu> wrote:

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


This is The Way if you really care about portability.  Autoconf, once you
get your head around what, why, and when it was created, makes for nice
Makefiles and projects that are easy to include in the 100 Linux
distributions with their own take on packaging the world.

>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20240619/866d895b/attachment.htm>


More information about the TUHS mailing list