[Top][All Lists]

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

Re: svn copy conflicts with autotools ?

From: Eric PAIRE
Subject: Re: svn copy conflicts with autotools ?
Date: Wed, 01 Dec 2004 14:42:16 +0100
User-agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0

I already thought that this was the good solution, but I have always been puzzled by the fact that I never see it yet implemented (such as in gnu projects). I agree on everything, but you have to make these generated files ignored to your versioning
system, and there should be a way to remove them easily.

It this solution is so obvious, I don't understand why autotools developers have not already set up a tool which automatically removes the files generated by the autotools
(perhaps this tool exists and I don't know about).

P.S. The problem is less important with CVS, because CVS keeps modification dates
(which generates others problems in the versioning system)

Henrique de Moraes Holschuh wrote:

On Wed, 01 Dec 2004, Eric PAIRE wrote:
3) I have set up a tag with 'svn copy' so that the tagged version is the exact
  copy of the version in the 'trunk' directory.
4) Another user gets the tagged version with a 'svn co' and runs 'configure'
  on it. And now ...

As it was once so eloquently explained to me by a senior Debian developer
when I asked exactly the same question (but for CVS, since Subversion didn't
exist yet):  "If you're doing that, you're weird. Go away".

The translation for that would be:  Why the heck are you keeping
auto-generated files in a RCS system?  Get them out of there, they do NOT
belong in the repository!
Add a run-this-on-checkout script and proper rules to the makefiles to run
the autotools sequence if the autotools files are not yet available.

As for a bad autotools setup on the build system, well, document properly
what the build system has to have installed for the development versions.
Anyone doing development has to be at least capable of a proper build system
setup, no?

When you generate a release, run autotools before you make a
tar.bz2/tar.gz/.cab/whatever file that you're going to distribute.  This
way, all the autotools scripts are already built and have correct timestamps
inside the distribution archive. Normal users won't need to bother with
autotools configs, then, unless they muck with, or
something else like that.

reply via email to

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