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.
