On Tuesday 2012-05-29 16:31, Richard Guenther wrote:
I find patches touching autogenerated files unwieldy to maintain.
Why exactly?
For example, there is a new warning in automake 1.12 that moans about AM_PROG_AR being absent when intending to create a .la archive. So, one has to add a *1-line* patch to the package iff it used AM_INIT_AUTOMAKE([-Werror]). The expanded form, as you suggest, of this change would be a 270+-line patch. Second case: adding foo=bar; AC_SUBST([foo]) to configure.ac. That's a 2-line patch. The more Makefiles a package has, the bigger your patch gets. And dare you made a typo.
Running autoreconf is, in many cases, not a problem, and upstream developers should be asked to try tuning their software to make it work with newer autotools suites, just like compiling with libfoo-devel-1.24 when the actual requirement that has been specified in the INSTALL/README reads "libfoo >= 1.23".
Well, "in many cases" - apart from those in the list that started this thread.
I've been through a few from the list, and they have been in the large part the AM_PROG_AR-type kind.
autotools are not trying to maintain compatibility,
They damn well do. You can still specify (IMHO way too many) old forms. Prime examples are AC_INIT([src/foo.c]) AM_INIT_AUTOMAKE([pkg], [version]) Just like with recent g++ releases, what was added in automake 1.12 was some form of stricter checking. It's just that it errors out on everybody who though using -Werror was fun.
At least you create issues with building a package for multiple distributions if you use autoreconf.
Clearly this is not the case if done right. Else I'd be having repeated bug reports about all the (upstream) projects of mine. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org