Autotools-generated 'configure' & 'Makefile.in' considered binaries?

[Maxime Devos]

Hi guix,

Quite some packages in Guix use the Autotools system.  In this system,
a 'configure.ac' and 'Makefile.am' script / makefile is written, from
which 'autoconf' & 'automake' generate a very long bash script and a
Makefile.in.  Depending on the maintainer of the upstream package, this
'configure' and 'Makefile.in' are sometimes included in release
tarballs.

This seems in conflict with:

  * (guix)Submitting patches: ‘Make sure the package does not use
    bundled copies of software already available as separate
    packages.’

    Autotools packages have a 'config.guess' and 'config.sub' script
    that need to be updated whenever there's a new architecture.  As
    such, for some packages, these need to be replaced for aarch64,
    powerpc or risv64.  There are also some packages with very old
    configure scripts that don't support --build/--host/--target,
    which could gain --build/--host/--target support by just
    regenerating them.

    This also makes ensuring a package does not contain any malware
    much harder, because the configure script (and related files)
    needs to be read in their entirity.

 * When an upstream tarball contains .so, .dll, .a, etc. binaries,
   they are removed downstream in a snippet.  Why would the Autotools
   be an exception?

For some ‘early’ packages (gcc, glibc, binutils, ...), there's a
circularity problem, so building 'configure' and 'Makefile.in' from
source might not always be possible, but WDYT of building 'configure' &
'Makefile.in' from source for packages where it does not result in
bootstrapping problems?

Greetings,
Maxime.

signature.asc
Description: This is a digitally signed message part