On Fri, 05 Feb 2010, Julian Andres Klode wrote: > > Adding an optional command to debhelper that likely does not do the > > right thing for a fairly large percentage of packages (my experience > > with running autoreconf and having it actually work, in the real world, > > is not exactly stellar) would be a departure. > This practice is recommended by the README.Debian of autotools-dev.
Autotools-dev "best practices" assume you did a full job on the build system, and got it fixed if it is not properly rebuilding itself from scratch. It also assumes you sent any autogenerated files to kingdom come in the debian/rules clean target (or moved them out of the way, if you're into that). If that stuff is in any way horked, or if it hits one of the autoreconf bugs/shortcomings (e.g. autoreconf can't take a -I for aclocal), you need to do something different. > > Is there really no better way to isolate autoreconf's changes to keep > > them out of the diff? Since debhelper already supports running configure > > and build in a temporary build directory, perhaps the simplifying > > assumption needs to be that if autoreconf is used, a build directory has > > to be used. > You'd need to copy the whole source tree into the build directory for > autoreconf to work, as far as I know. AFAIK, that's correct. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
