[Top][All Lists]

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

Re: built files in CVS

From: Steve M. Robbins
Subject: Re: built files in CVS
Date: Mon, 24 Sep 2001 07:46:26 -0400
User-agent: Mutt/1.3.22i

On Sat, Sep 22, 2001 at 04:59:31PM -0400, Derek Robert Price wrote:
> "Steve M. Robbins" wrote:
> > Hello,
> >
> > I presume the automake developers track the CVS tree and
> > frequently build new versions of automake for testing.
> > Could you let us in on the secret to minimizing the following
> > annoyance?
> >
> > The CVS tree includes things like  But this file
> > is also generated from when I build automake.
> > The next time I do "cvs update", I get a conflict because
> > of stupid changes like:
> >
> > address@hidden
> > <<<<<<<
> > # generated automatically by automake 1.4i from
> > =======
> > # generated automatically by automake 1.5a from
> > >>>>>>> 1.338
> >
> > I normally end up removing the file, running cvs update again,
> > then rebuilding.  What do the rest of you do?
> >
> > -Steve
> You shouldn't see this problem unless someone rebuilt the `'s
> with a new version of Automake and checked them in since the last time you
> checked out. 

Yes and it is a fairly common occurence. is up to
revision 1.338 while is at revision 1.176.  Other 
CVS-controlled built files show a similar albeit less drastic

> One of the simple ways to avoid this is to have the
> developers on your project agree and standardize on the same version of
> Automake.

That is an unnecessary burden on the developers.

> I don't know of another workaround for this other than the one you mention.
> With CVS, we have a toplevel script, `' which can be run to
> avoid rebuilding automake and autoconf files after a fresh update or
> checkout.  [...] 
> I think I've
> heard of similar scripts being used on other projects, but I couldn't name
> any.  Copy of script attached.

Other projects with which I'm familiar take a different approach:
don't check in built files.  To bootstrap from a fresh CVS checkout,
one can supply a script to run "automake, aclocal, etc" in sequence.
The difference with your approach is that the script needs only be run
ONCE --- after the first checkout --- rather than once per update.
Many many projects take this path, including very large ones like

Clearly, built files can be recovered from their sources, so why
put them into version-control?


by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

reply via email to

[Prev in Thread] Current Thread [Next in Thread]