Re: what is autotools, what is gnulib

[Paul Smith]

On Thu, 2024-05-09 at 23:16 +0200, Bruno Haible wrote:
> Paul Smith wrote:
> > If all we cared about was portability to GNU systems we could do
> > away with 99% of autotools and gnulib; basically everything except
> > portability between older and newer versions of glibc-based
> > systems.
> 
> While it is true that Autotools and Gnulib care a lot about
> portability, they are also significantly useful for packages that
> target *only* glibc-based systems.

I did say it was still useful in the context of supporting historical
versions of glibc-based systems.  In addition to that of course there
are differences related to hardware architectures which I meant to
include but forgot.

By "only caring about GNU systems" I mean: no libc except glibc, no
compiler except GCC / binutils, no shell except bash, no make except
GNU Make, no shell utils other than GNU shellutils, no awk except Gawk,
no sed except GNU sed, etc. etc.  And since there are only a few
kernels that are supported by glibc, there are few kernel-level
differences that need to be considered.

Many of the extra capabilities provided by gnulib could simply be
subsumed by glibc, either directly or as an extra library: there's no
need to provide these with each software package if we only support GNU
systems; we can just assume they are always present.  Clearly glibc
needs a POSIX interface so that non-GNU software can be ported to it,
but GNU software doesn't need to limit itself to that interface: it can
rely on all extended GNU behavior without checking if it exists.

This is a purely academic discussion as I definitely do not suggest
this is appropriate (in fact my original email argued against it).  For
example, abandoning small targeted libc's that already exist, like
musl, and precluding support for any future system unless it first
ported ALL the above software, would definitely be A Bad Thing, both
for GNU in particular and for Free Software in general.

> In particular, the following are significantly useful in this
> setting:

With respect to automake, if we could require that nothing but GNU Make
was used, IMO automake per se would not be needed and its entire
implementation could be provided as a boilerplate makefile (or possibly
two) that would be included by the package makefile, without requiring
Makefile.am or Makefile.in.  Autoconf would either generate a makefile
setting appropriate variables which would be included, or the
boilerplate makefile could digest the contents of config.status at
runtime and set make variables appropriately.

This boilerplate makefile could also always be present as a standard
part of a GNU system and would not need to be included in source
packages.

Again, I do not suggest this.