Re: automake 1.5
On Mon, 08 Oct 2001, Domenico Andreoli wrote:
> > > i put automake in Build-Depends because of its ability to make
> > > generated makefiles call itself. i started using versioned depends
> > > because on transition to autoconf 2.50 i though automake changed
> > > in another beast too.
autotools will try to auto-update their state in the Makefiles, which is
more often than not a total pain.
I've a sequence of touch foo && sleep 2s && touch bar in my debian/rules
clean target to stop that nonsense.
(Of course, I make sure I'm shipping all the autotools-generated stuff in a
sane and consistent state).
> > But those files cannot be regenerated because of wrong timestamps induced
> > by applying .diff.gz.
Yes.
> i keep almost all of my packages under cvs and i can see that sometimes,
> after the first debuild, all my Makefile.in get modified. then, usually,
Well, what the hell are automatically-generated files doing in your cvs
tree? As long as you keep anything like that around, it will try to drive
you nuts...
> i decide to call libtoolize;aclocal;automake;autoconf; right to be sure
> everything is up-to-date. then i put automake/autoconf in Build-Depends to
> be sure that those strange users (the autobuilders :) ) install everything
> that might be required for build.
That's the wrong way to go about it IMHO. I've found that doing it at cvs
export time, properly, and then adding the proper touch magic to the
debian/rules clean target (so as to stop the timestamp skew caused by the
diff) will:
1. Save on autobuilder CPU time, as _nothing_ of the .in/.am gang need
to be reprocessed.
2. Save on build-depends, since you need not automake, autoconf or libtool
in the build-depends.
3. Save on sanity. No more insane bugs because someone else's
auto*/libtool is stoned.
> i have two other packages that build all from scratch calling libtoolize;
> automake; autoconf; right from the upstream configuration script, they do
> not even ship with this stuff, so i have to depend on
> automake/autoconf/whatever.
Well, not really. You can generate that and package them in the .diff. I am
not sure this is the best course of action, though... but I'd go for it.
> btw: cvs gets confused by changes made in Makefile.in-s by automake (and of
> course the ones in ./configure made by autoconf and all the other made by
> aclocal, libtoolize) and it tries to apply them also when i import a new
> upstream version. the result is some extra work by hand (i hate it).
As I said, do not let CVS near anything like that. .cvsignore them to keep
the upstream cruft away from your tree, and remove them from your working
directory. You'll need an autogen.sh-like script that calls the proper
auto*/libtool sequence on cvs export, and either get your debian/rules files
to call it if configure is missing, or get CVS to run the script
automatically on exports.
> i would be very very happy to solve this problem and i would be very
> thankful towards anybody suggesting a solution.
Well, see my fetchmail source package. I keep it (and build it) straight out
cvs using cvs-buildpackage. It has an (somewhat overengineered) autogen.sh
script that gets called by debian/rules.
--
"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
Reply to: