[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Build-depends: autoconf, automake ?

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 ...


Reply to: