Re: automake 1.5
On Mon, Oct 08, 2001 at 05:17:34PM -0300, Henrique de Moraes Holschuh wrote:
...
>
> I've a sequence of touch foo && sleep 2s && touch bar in my debian/rules
> clean target to stop that nonsense.
why sleep 2s?
> > 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...
cvs-inject puts in cvs everything the upstream tarball contains (yes i know
i should talk with upstrem, i'll do), so i get libtool and other files too.
> > 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 would do this way if i were an upstream, but i think not every developer
works like i'd do.
> > 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.
>
hmmm.. yes, if i can be sure automake and friends will not be called again
> > 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 cannot remove any Makefiles.in otherwise whoever wants to compile my
packages *must* run auto-tools :(
> > 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.
>
i'll do
thanks
domenico
-----[ Domenico Andreoli, aka cavok
--[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Reply to: