On 1 July 2014 02:02, Theodore Ts'o <tytso@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
