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

[Liliana Marie Prikler]

Am Mittwoch, dem 30.03.2022 um 14:04 +0200 schrieb 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?
Note that many autotools-based packages already require the addition of
autoconf and friends due to being pulled from git.  That being said,
it's somewhat hard to argue for completely dropping them, because
a. simply matching files via ".in" suffix would be error-prone
b. autoreconf should regenerate these files regardless
Therefore, my counter-proposal would be to just simply always run the
bootstrap script or autoreconf, even if the respective files are
tarballed, as well as adding autoconf and automake to the implicit
native inputs of gnu build system.

> For some ‘early’ packages (gcc, glibc, binutils, ...), there's a
> circularity problem
The obvious solution to which would be to implement m4 in mes :)

> [B]uilding '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?
See above, but to reiterate, I'm generally in favor.

Regarding tooling support, I think autotools should have an option to
build a non-bootstrapped dist tarball.  If more upstreams produced such
stripped tarballs, we wouldn't even be having that debate.

Cheers