autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future plans for Autotools


From: Nick Bowler
Subject: Re: Future plans for Autotools
Date: Fri, 22 Jan 2021 14:48:11 -0500

As always, thanks for all your effort Zack!

I wanted to share some of my thoughts on Autoconf and friends.  Maybe I
wrote too much.

For me the most important requirement of the GNU build system is that
it must be as straightforward as possible for novice users to build free
software packages from source code, with or without local modification.

This is what empowers users with the benefits of free software.  If
users are unable to build or modify the software that they use, they
are unable to take advantage of those benefits.

For me, every other consideration is secondary.

The interface consistency prescribed by the GNU coding standards goes
a long way: you learn the steps for one package and can apply that
knowledge to almost any other package.

The trend towards requiring everyone to build from VCS snapshots
and requiring zillions of specific versions of various build tools
is concerning.  Unfortunately I think many developers don't really
care about the user experience when it comes to building their software
releases from source.

This brings me to another important strength of the GNU Build System: if
I prepare a package today I want to be confident that people will still
be able to build it 5, 10, 20 or more years from now.

Now obviously we can't predict the future but we can look to past
experience: just today, I unpacked GNU Bison 1.25 (ca. 1996) on a modern
GNU/Linux system, running on a processor architecture and distribution
that didn't even exist back then, and it builds *out of the box*.

Typical issues encountered with old GNU packages are usually very minor
if you have any problems at all.  For a more complex example, I tried
building glib-1.2.10 (ca. 2001).  I had to update config.sub/config.guess
to the latest, set CC='gcc -std=gnu89' (because the code does not work with
C99 inline) and edit one line of code to disable use of an obsolete GNU C
extension (both compilation problems are due to not following the Autoconf
philosophy and using version checks instead of feature checks, oops!)

My general experience with CMake is that you probably can't build any
old packages because whatever version of CMake you have available simply
doesn't understand the package's build scripts, and the version which
could understand them just doesn't work on your system because you have
a newer processor or something.

I don't have enough experience with Meson to say.  Mainstream free
software packages have only very recently started using it.  On the
GNU side, glib-2.60 (ca. 2019) converted to meson and I am able to
build it.  If possible, I will have to try again in 2039.  I bet the
autoconf-based glib-1.2.10 tarball from 2001 will still mostly work,
and so will the 1996 version of GNU Bison.

Cheers,
  Nick



reply via email to

[Prev in Thread] Current Thread [Next in Thread]