On Tue, 2009-02-24 at 14:09 -0800, Toshio Kuratomi wrote: > > Aside from that, I'd say did you read, and try, the advice you were > > given in the failure log? > > > > "You have another version of autoconf. It may work, but is not > > guaranteed to. > > If you have problems, you may need to regenerate the build system entirely. > > To do so, use the procedure documented by the package, typically `autoreconf'." > > > > i.e., see if it works with autoreconf. IMHO it is generally a good idea > > to use autoreconf rather than just autoconf anyway, because just using > > autoconf is more likely to fail if, say, we go up a major version of > > autoconf, and upstream source doesn't have a new release in that time. > > autoreconf has at least a better chance of succeeding in that situation > > (though it won't always). > > In the most recent debate, someone said that autoreconf should never be > run. Wish you had been there to lend another perspective :-) I can see that argument in terms of making what the package does somewhat more reliably reproducible on Joe Random System, but in terms of what works best in a controlled environment (i.e. within a distribution's repositories), my practical experience is that autoreconf is probably a good idea. I do actually have rather a lot of practical experience in this area, as I rebuilt several hundred very old and unmaintained packages for Mandriva over the last year or two. I came across rather a lot of cases where just running 'autoconf' wouldn't work any more (because you were running autoconf 2.6 on stuff that had been generated by aclocal 1.4 or something...), but 'autoreconf' - to re-generate everything - would work. So from my experience of nasty old crufty code, I would say that 'autoreconf' is somewhat more reliable than running the individual components. There are times when the scripts are sufficiently nasty and broken that they won't work with modern versions of the autotools whatever you do, though. I can see the argument for patching configure or Makefile.in directly (rather than configure.ac or Makefile.am ), too. It doesn't upstream and is rather harder to read, I'd say, but it does have the advantage that it doesn't depend on the behaviour of the autotools, which changes over time. Debian's policy is this way, FWIW. Oh, and thanks to Dan for reminding me that using 'autoreconf -i' is the best way to do it. Some of the tools fail by default if certain 'required' files are missing. autoreconf -i just creates any missing files automatically. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
