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).
Thanks,
Eric
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 Makefile.am, configure.in or something else like that.
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
