On Thu, Jun 20, 2024 at 9:45 AM Lyndon Nerenberg (VE7TFX/VE6BBM)
<lyndon(a)orthanc.ca> wrote:
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.
This is outright claptrap and nonsense. In the latter half of the
90s I was responsible for writing installers and generating
platform-native packages for about a dozen different commercial
UNIX platforms (AIX, Solaris, Irix, HP/UX, OSF, BSD/OS, ...). Each
of these package systems was as different as could be from the
others. (HP/UX didn't even have one.)
Strong language for something that is easily measured by looking at a
contemporary package collection. That's great for you and whatever
this was but it is a simple fact that autoconf is the most common tool
for Linux and rejecting it or something like cmake that has widespread
adoption makes life more difficult for distributions. Go look at a
random deb or rpm spec or ebuild or apk or whatever you wish, these
all have inbox support for autoconf and have to impedance mismatch
your clever custom jobs.
That entire process was driven by not very many lines
of make
recipes, with the assistance of some awk glue that read a template
file from which it generated the native packages. And these were
not trivial software distributions. We were shipping complex IMAP,
X.400 and X.500 servers, along with a couple of MTAs. Our installers
didn't just dump the files onto the system and point you at a README;
we coded a lot of the site setup into the installers, so the end
user mostly just had to edit a single config file to finish up.
The set of people that interact with make is minimal in relation to
the userbase of contemporary unix. Binary distribution is the norm
and has been for decades.
--lyndon