On Fri, 2008-07-18 at 07:21 -0700, Kean Johnston wrote:
> automake injects rules into the Makefile.in files that will cause it
> to re-run the autoconf/automake/libtoolize programs if it detects that
> configure.ac is more modern than configure, or if a Makefile.am is more
> modern than its corresponding Makefile.in.
I've run into this case myself, with CVS.
My workaround was to, while preparing checked out sources for build,
force all of the file timestamps to the current time, which prevents
make from deciding that any of the sources are out of date with respect
to one another. This also prevented the build system from trying to
regenerate locale files when I would make fixes to source code files.
> every system that I build that tree on will produce potentially
> different results, because each system could have slightly different
> versions of autoconf / automake etc installed.
That's not a terribly compelling argument; you'll also get different
results if you have (a) a different version of gcc, (b) a different
version of any library the package depends on, or (c) an optional but
compiled-in-by-default-if-found dependency installed on one system but
not another. If you want consistent results, you need a consistent
build environment.
In my case, the issue was more that the build would frequently fail
because the source code was not compatible with the version of autotools
installed on the build host.
> File metadata is as important to many developers as file contents. If I was
> a developer using rcs,cvs, sccs, pvcs, clearcase or Perforce, which can all
> keep track of timestamps
It is disingenuous to say that RCS or CVS can keep track of timestamps,
for two reasons:
1. They record only one time per file version. By default, this is
the time at which you commit the file. If you untar an autoconf-using
software release, import it into CVS, and then check it out, you will
get exactly the same autotools issue as you describe in your use case.
If you import the source tree using the -d option then you have
discarded the ability to use your repository's date history; a checkout
of the repository as of "yesterday" will falsely include most or all of
the source code you imported, even though it wasn't in your repository
at that time. Moreover, RCS doesn't even have an "import -d" analog.
2. Although a CVS initial checkout will use the timestamp recorded in
the repository for the most recent rev (normally the commit time,
possibly not if you use import -d), files changed by "cvs update" will
always have the current timestamp. So even if you used import -d, only
the initial checkout of an autotools-using software project will build
as you desire; if you update your working copy the next day and try to
build it, it may fail due to timestamp issues.
I can't speak to the other revision control systems, but since the
statement is not true of RCS or CVS I wouldn't trust that it's true of
the others.
All that said, I'm not necessarily opposed to Subversion recording mod
times. I just think you're fudging a bit in these arguments for it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-19 05:20:41 CEST