Generated files in e2fsprogs git repo

Generated files in e2fsprogs git repo

[Burton, Ross]

Hi,

Would anyone object to a patch set to remove all generated files
(aclocal.m4, configure, intl/*, po/Makefile.in.in, etc) from the
e2fsprogs git repository?  They'll still exist in tarballs, but anyone
building from git would need to run autoreconf to regenerate them -
the plus side being that the shipped aclocal.m4 won't be forcing
archaic macros onto users.

Ross

Re: Generated files in e2fsprogs git repo

[Theodore Ts'o]

On Mon, Jun 30, 2014 at 05:52:29PM +0100, Burton, Ross wrote:
> 
> Would anyone object to a patch set to remove all generated files
> (aclocal.m4, configure, intl/*, po/Makefile.in.in, etc) from the
> e2fsprogs git repository?  They'll still exist in tarballs, but anyone
> building from git would need to run autoreconf to regenerate them -
> the plus side being that the shipped aclocal.m4 won't be forcing
> archaic macros onto users.


I don't trust autoreconf.  Different versions of autoconf can end up
with different incompatible versions of autoconf macros, and I have
seen some rather disastrous failures as a result.  That's why I update
autoconf under my control, and if you run autoreconf as a user, and it
breaks because the "archaic macros" work, and the "new shiny" macros
fail, that's your problem, and I will laugh at you....

      	     	  	       	      - Ted

Re: Generated files in e2fsprogs git repo

[Burton, Ross]

On 1 July 2014 02:02, Theodore Ts'o <tytso@mit.edu> wrote:
> I don't trust autoreconf.  Different versions of autoconf can end up
> with different incompatible versions of autoconf macros, and I have
> seen some rather disastrous failures as a result.  That's why I update
> autoconf under my control, and if you run autoreconf as a user, and it
> breaks because the "archaic macros" work, and the "new shiny" macros
> fail, that's your problem, and I will laugh at you....

I disagree with this position: if you're the one releasing the
tarballs then you have this control anyway - people building from git
have a higher level of technical competence assumed and using the
right versions of autoconf isn't rocket science.

My context is that we're building distributions and for every package
that uses autotools we forcibly autoreconf because the
upstream-provided configure is generally insufficient: for example
upstream libtool needs patches to cross-compile correctly, and there's
a long lag (several years) between a new architecture being developed
(two recent examples: x32 and aarch64) and it being wide-spread enough
to be in every generated configure script.

e2fsprogs is one of the handful that breaks when we do this, because
aclocal.m4 contains macros that don't come from the system (AX_TLS and
CHECK_GNU_MAKE).  Simply moving these macros to acinclude.m4 should
solve this problem for us: autoconf defines that aclocal.m4 contains
copies of macros from the system, but acinclude.m4 contains
project-specific macros.  I'll send a patch shortly to implement this
split.

Ross

Re: Generated files in e2fsprogs git repo

[Theodore Ts'o]

On Tue, Jul 01, 2014 at 10:55:51AM +0100, Burton, Ross wrote:
> 
> My context is that we're building distributions and for every package
> that uses autotools we forcibly autoreconf because the
> upstream-provided configure is generally insufficient: for example
> upstream libtool needs patches to cross-compile correctly, and there's
> a long lag (several years) between a new architecture being developed
> (two recent examples: x32 and aarch64) and it being wide-spread enough
> to be in every generated configure script.

I don't use libtool at all, because I'm not a masochist.

	https://plus.google.com/+TheodoreTso/posts/89xgTY49Rvk

I assume the real issue is that you need an updated version of
config.guess and config.sub.  That can be easily updated without
having to use autoreconf, which is using an elephant gun to kill a
flea.

> e2fsprogs is one of the handful that breaks when we do this, because
> aclocal.m4 contains macros that don't come from the system (AX_TLS and
> CHECK_GNU_MAKE).  Simply moving these macros to acinclude.m4 should
> solve this problem for us: autoconf defines that aclocal.m4 contains
> copies of macros from the system, but acinclude.m4 contains
> project-specific macros.  I'll send a patch shortly to implement this
> split.

I'll look at that patch; if it's clean, I won't have a problem with
it.  But I'd strongly encourage you to consider just updating
config.guess and config.sub for those projects that have the good
taste not to use libtool.

Regards,

						- Ted