On Thu, 28 Jun 2007, Mark Taylor 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
>> M applications/convert/iraf/libsys.a_pc_linux_gnu
>> M applications/convert/iraf/libos.a_pc_linux_gnu
>> M applications/convert/iraf/libvops.a_pc_linux_gnu
>> M applications/convert/iraf/libimfort.a_pc_linux_gnu
>> M applications/convert/iraf/libcompat.a_pc_linux_gnu
>>
>>
>> which mess up the 'svnversion' version number because it includes an "M"
>> in it to indicate that the tree was locall modified.
>
> Peter,
>
> if this sort of thing causes subversion trouble it sounds like the
> starjava locally modified files (ant/lib/ant-*.jar) could be a problem
> waiting to happen if/when we go over to svn/sourceforge. I've never
> really worked out why these files get locally modified but I presume
> there's some reason. Any comment on whether this is likely to be
> difficult to get round?
Hi Mark,
no need to worry, these files are just annoying as they mess up the result
from svnversion, not an issue for subversion itself.
Svnversion is a command that just looks at all the files in your checked
out source and outputs some number that is supposed to represent the
state. If all the source files match the repository state (from the last
checkout) then you just get a single number, which means you know what was
built.
As for fixing the ANT problem, I expect I could work around it, but at
some extra maintenance cost, so it's not a high priority.
Cheers,
Peter.
|