[TUHS] Re: Building programs (Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register

["Theodore Ts'o" <tytso@mit.edu>]

On Sun, Jun 23, 2024 at 07:16:35AM +1000, David Arnold wrote:
> 
> As an example, mentioned up-thread, building on Ultrix in 2024: you
> need to test and work around a bunch of things that have been fixed
> on anything updated since the mid-90’s to get a clean build on
> Ultrix, SunOS-4.x, etc.  Your average Linux or macOS user sees this
> as pointless time wasting.

In practice, the set of OS's which a particular software package using
autotools will change over time.  For me and e2fsprogs, just to give a
concrete example, there is the set of packages for which I personally
have access to.  Many years ago this included Ultrix, OSF/1, AIX,
Irix, and Solaris; and when I did have easy access to those machines,
it wasn't hard for me to do a test compile, and when things broke, it
was easy enough to add (or write) an autoconf test, and fix that
particular build or test breakage.  There would also be OS's for which
I did not have direct access --- for example HPUX, where (a) sometimes
the portability work that I did for AIX or Solaris would address eome
portability issue on HPUX, or (b) someone building the package on HPUX
would send me a bug report, and in general, it would be really easy to
fix up the sources so that things worked on HPUX.

So surprise, Autotools is not magic.  It will not magically make your
code portable.  However, for someone who *wants* to make portable
code, I've found autotools to be the most developer friendly way of
supporting portable code.  Certainly, it's ***way*** more
user-friendly than imake, for which I have had the misfortune of
having to have used, and because autotools is test features, and not
OS's, it's much easier to support than needing to have a manually
curated set of #define's for each OS that you want to support.  (I
can't beieve people think that's a good idea; I would find that
incredibly painful and would involve much more work.)

What does happen over time, though, is that when the maintainer, or
the development commuity at large, loses access to an hardware and/or
OS combination, support for that that platform will start to rot, and
things will gradully start breaking as new feature development will
accidentally add some dependency which can't be guaranteed everywhere.

Yes, you can have someone strictly trying to require that no advanced
feature beyond that which was available in BSD 4.3 be used, in the
name of portability, but sometimes there are real functional and
performance sacrifices that might get made if you do that.

> There’s no right answer here: someone is always annoyed at you.

Indeed, and there will always be people who want to backseat drive and
tell you that you should do things their way.  I find there's a lot of
religion wrapped up here, much like the choice of ed, vi or emacs....

	 	    	       	    	       - Ted