David Mankin wrote:
> On Saturday, October 12, 2002, at 05:15 AM, Bram Moolenaar wrote:
> >
> > Unfortunately CVS doesn't update the timestamp of a file, thus "make"
> > gets confused. I don't know a solution for this (not even A-A-P solves
> > this yet, still looking for a good idea...).
>
> Subversion (a developing SCM system: http://subversion.tigris.org/) has
> been struggling with this too. What they decided on is to never use
> repository timestamps. Instead, any time a file is updated by the
> subversion client, they let the OS update the timestamp so it remains
> at current. This was done explicitly to support make in this way.
>
> I personally find repository timestamps more valuable than the other
> kind. (Can we call them working copy timestamps?) Sometimes, though
> (e.g. in this make example), WC timestamps are more useful. For an
> ideal solution, maybe it could be a property of each file which kind of
> timestamp support is desired. Or maybe a property of a particular
> working copy or even repository.
Any kind of timestamp gets confused when using a networked file system
with different time settings (one hour off is not uncommon this month).
> What is really needed is a smarter Make that keeps track of which
> "version" (timestamp, checksum, or SCM version-based) of each file
> contributed to the build of a derived file. Then it should remake when
> the contributing files are different, not just when a contributing file
> has a timestamp newer than the derived file. Then there would be no
> problem sticking with repository timestamps. But the need to work with
> the existing Make tool(s) probably prohibits this as a realistic
> solution in today's SCM tools.
A few tools use signatures. A-A-P is one of them. That solves the
problem for most situations. You can check out files and apply patches
in any sequence, the only thing that matters is whether the file ends up
being different. This also works for object files, thus if you change a
comment the file will be compiled, but when the resulting .o file is
identical nothing else happens.
The only situation where this doesn't work is when two files are updated
and one file has been generated from the other. For example,
configure.in and configure are both changed. This suggests that
autoconf must be run, since the signature of configure.in indicates it
has changed. But not everbody has autoconf installed, thus this might
fail (and autoconf 2.5x is not compatible with 2.13, thus it is
important to avoid running autoconf). Distributing the generated
configure file helps. But how can the build tool see that this
configure file was generated from this configure.in and does not need
updating even though its signature changed?
For A-A-P I thought of the solution to distribute the signatures as
well. For the dependency where configure is generated from configure.in
you add an attribute that specifes the signatures are stored in the
"confsign" file. This file is patched/checked out together with the
files, thus the build tool knows the signatures when autoconf was last
run.
configure {signfile = confsign) : configure.in
:sys autoconf
Another solution would be to put the signature of configure.in inside
the generated configure. That allows checking if configure is outdated
without having to distribute an extra file or updating version numbers.
My experience with the extra signature file is that it's easy to forget
to distribute the updated version.
--
hundred-and-one symptoms of being an internet addict:
216. Your pet rock leaves home.
/// Bram Moolenaar -- Bram_at_moolenaar.net -- http://www.moolenaar.net \\\
/// Creator of Vim - Vi IMproved -- http://www.vim.org \\\
\\\ Project leader for A-A-P -- http://www.a-a-p.org ///
\\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 14 13:46:37 2002