Re: built files in CVS

[Derek Robert Price]

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

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.  You do have to be careful to avoid running this script after you
have changed configuration files, but it's convenient when you are
attempting to support people who might be using a heterogeneous set of
Automake and Autoconf versions, sometimes build the source from CVS, and
don't usually change the Automake/Autoconf config files.  I think I've
heard of similar scripts being used on other projects, but I couldn't name
any.  Copy of script attached.

Derek

noautomake.sh
Description: Bourne shell script