On Thu, 28 Jun 2007, Tim Jenness wrote:
> On Thu, 28 Jun 2007, Peter W. Draper wrote:
>
>> On Thu, 28 Jun 2007, Tim Jenness wrote:
>>
>> > Just done another make world, this time 32-bit and we are close to
>> > being clean now with an svn status after the build. Outstanding
>> > problems are:
>> >
>> > M applications/extractor/extract/Makefile.in
>> > M applications/extractor/extract/src/Makefile.in
>> > M applications/extractor/extract/src/fits/Makefile.in
>> > M applications/extractor/extract/src/wcs/Makefile.in
>>
>> Tim,
>>
>> in my builds these files are not modified and cannot be removed. It
>> looks like you or something ran automake in "extract/" any ideas how
>> that happened?
>
> not that I know of. Just did a fresh checkout and make world.
>
> The diff indicates that install-svnversion has been added to the
> install-am target, so these look like reasonable patches.
Hi Tim,
OK, now I understand... The problem is that subversion doesn't preserve
commit times, so on checkout you get the creation time of the file. Making
this worse the order of the checkout doesn't match the commit order. So
the timestamps of all files can be effectively randomised.
You are supposed to be able to get some relief from the client side as you
can set "use-commit-times = yes" in your ~/.subversion/config file, but it
doesn't look like the import of these files preserved the commit times, so
that doesn't work for us (and if it did would require all checkouts to
switch on this option).
The upshot is we cannot have a committed state that depends on the
timestamps of the files, or, like in this case, we'll get files that are
not supposed to be re-generated being regenerated anyway. This effects a
lot of the thirdparty code (in fact I saw an instance of this on my first
checkout build during the bootstrap of automake, and dismissed it as a
little local difficulty, that killed the build, not just give a few
modified files).
Maybe the best option here is to fix up this issue during the bootstrap
phase (we could just say have a optional local file that listed these
files in the timestamp order required and just touch them), that would
make this problem go away permanently. Unless there's a better idea?
Cheers,
Peter.
|