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

[Maxime Devos]

Liliana Marie Prikler schreef op wo 30-03-2022 om 20:55 [+0200]:
> 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.

It should be possible to look for ‘# Generated by GNU Autoconf’ and ‘#
Makefile.in generated by automake’ lines in some 'find-generated-
autotools-fies’or something.

Adding autoconf & automake seems a bit much to me (gnu-build-system is
not necessarily autotools-build-system, the exact required version of
autoconf & automake can vary), but otherwise your proposal seems good
to me.

> > 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.

Yes, would be nice if upstreams could choose to opt-out.  Or maybe opt-
in instead.

Greetings,
Maxime.

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