[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-devel
Subject:    Re: automake 1.5
From:       Henrique de Moraes Holschuh <hmh () debian ! org>
Date:       2001-10-09 17:32:25
[Download RAW message or body]

On Tue, 09 Oct 2001, Domenico Andreoli wrote:
> 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?

Call me paranoic. I use 2s to make sure even the most braindamaged
filesystem out there will not screw up which file is older.

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

cvs-inject puts in cvs everything shipped in the tarbal, because that's how
it should behave. It does not mean your copies have to carry those files.
cvs checkin, checkout and update will cheerfully obey your .cvsignore files
and keep that stuff out of your tree.

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

That has little to do with being upstream. It's a sane way to do it if
you're downstream (i.e. the Debian maintainer) of a package...

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

You can, if you add the proper touch magic. If the user modifies the files
and then tries to build, it's his problem; he better have a proper, working,
compatible autotools build environment...

> i cannot remove any Makefiles.in otherwise whoever wants to compile my
> packages *must* run auto-tools :(

You can, and should remove them from CVS. You must regen them on cvs export
time.  Removing from cvs has little to do with shipping them in the tarball
or diff file.

-- 
  "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-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

[prev in list] [next in list] [prev in thread] [next in thread]