Re: svn copy conflicts with autotools ?

[Eric PAIRE]

Hello Gary,

Gary Thomas wrote:

> Bonjour, Eric :-)
>
> On Wed, 2004-12-01 at 04:38, Eric PAIRE wrote:
>  
>
> > Hi all,
> >
> > Here is the description of a problem met with subversion and autotools.
> > If anybody has a clean solution, let me/us know:
> >
> > 1) I have a project using the autotools for the environment management.
> > 2) The project compiles without any problem in the 'trunk' directory.
> > 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 ...
> >
> > The problem is that all the dates of the checked out files have been 
> > modified,
> > and when running 'make', the first thing run is 'autoconf' and 
> > 'automake', thus
> > modifying source directory files (configure, ...). It was even worst in 
> > our case, as
> > the autotools installed on the machine were too old and 'make' stopped 
> > without
> > having built anything :-( :-( The result is that checking out a tagged 
> > version may
> > lead to an unusable source tree (at least a tree needing some source 
> > file modifications).
> >
> > This is the reason why I don't think it is a good thing that the 
> > subversion philosophy
> > of timestamps conflicts with autotools one. I am looking for a solution 
> > that would
> > allow a checkout to avoid rebuilding source files when not necessary. 
> > Timestamps
> > need to be preserved somewhat, and I think that the way subversion 
> > manages currently
> > timestamps should be coherent with autotools (or autotools should be 
> > modified to
> > handle subversion philosophy), and in particular when doing a 'svn copy'.
> >
> > Thanks for your comments (and your solutions),
> > Eric PAIRE
> >    
>
> Doesn't setting "use-commit-times = yes" in your local configuration
> file (~/.subversion/config) solve this?  The files will have the 
> timestamp of when you committed them last when you check them out.
> Thus, you set them up and commit them to the trunk.  All is well with
> the auto-tools.  Then copy to your branch/tag.  When you check them out
> you'll get the same timestamp if as when you committed them if you have
> this option set.
>
>  
Unfortunately, I tried this feature, and it does not solve easily my particular
problem : I need to run multiple 'svn commmit' in order to respect modification
time of all the tools generated which means multiple 'svn copy' in the right
order when tagging a version (a real pain for doing a simple tag :-(

For now, the best existing solution is to not commit autotools generated files
under source control (which makes sense), and to regenerate them inside a
'svn export' tree. But what keeps on puzzling me with this solution is that
you need to modify the source tree of what you 'svn co' in order to be able to
use the package delivered.

Probably the right solution would be to modify the autotools to only get in the
source tree a generic 'configure' able to generate at the very beginning all
autotools files in the object tree without having to modify anything in the
source tree.

It remains clear that autotools and subversion are somewhat in conflict that
should be clearly fixed by both sides, saying what is the solution that is
jointly recommended.

Best regards,
Eric