Re: built files in CVS

[Steve M. Robbins]

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 Makefile.in.  But this file
> > is also generated from Makefile.am when I build automake.
> > The next time I do "cvs update", I get a conflict because
> > of stupid changes like:
> >
> > address@hidden Makefile.in
> > <<<<<<< Makefile.in
> > # Makefile.in generated automatically by automake 1.4i from Makefile.am.
> > =======
> > # Makefile.in generated automatically by automake 1.5a from Makefile.am.
> > >>>>>>> 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 `Makefile.in'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.  Makefile.in is up to
revision 1.338 while Makefile.am is at revision 1.176.  Other 
CVS-controlled built files show a similar albeit less drastic
discrepancy.


> 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, `noautomake.sh' 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
Gnome.

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

-S

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