On Mon, 27 Nov 2000, Matt Zimmerman wrote: > On Sun, Nov 26, 2000 at 02:40:51PM -0500, Steve Robbins wrote: > > > In light of the above, one solution that suggests itself is to just stick > > autoconf and automake in the Build-depends line, and > > > > 1. run "make maintainer-clean" in debian/rules(clean), to avoid diffing > > Makefile.in files, and > > > > 2. insert the proper sequence of "aclocal -I m4", "autoheader", > > "autoconf", etc in debian/rules(configure). > > > > > > Is it kosher to require auto* tools for building stuff? Are there > > pitfalls with this that I'm overlooking? What do other people do? > > What I do (for a package that modifies Makefile.am, but not configure.in): > > 1. Build-Depends: automake, autoconf > 2. In debian/rules: > - automake > - configure > - make > > I ship the upstream sources with the original Makefile.in's to avoid a huge > diff, and only patched Makefile.am's. I believe the automake-generated > makefiles will automatically rebuild .in from .am at compile time, but I run > automake explicitly to make it clear that this is what is intended. > > You should be able to do the same thing with autoconf/configure.in/configure.
I am glad to hear that I'm not alone ;-) I put "aclocal && automake && autoconf && autoheader" into debian/rules. It all works fine. But I did not understand what you said about original Makefile.in files. After building once, all the Makefile.in files will be patched, creating a huge diff. Is it the case that you re-copy the original Makefile.in files before generating the diff? I just keep running "dpkg-buildpackage -rfakeroot" until I get it right ;-) so my diff would include patched Makefile.in files. To prevent this, I put "rm -f `find . -name Makefile.in`" into the "clean" rule. That seems to work fine, too ... -S
