On Tue, 19 Jun 2007, Tim Jenness wrote:
>> On Sun, 17 Jun 2007, Tim Jenness wrote:
>>
>> > - one of the points of this is to provide a single revision number for
>> > the DR code. This requires that systems can work out the global
>> > revision. I think this means that for every 'make install' the output
>> > of svnversion (preferably from the build root directory) installs a
>> > file in $STARLINK/manifests (?) called 'starlink.version' (?) Does
>> > this sound reasonable?
>>
>> not sure I follow this. Do you mean that every component should update
>> starlink.version as part of its "make install", or that it should only be
>> done by "make world"?
>>
>> Surely either scheme can be duped as neither guarantees that the state of
>> the binary installation matches that of all the source files. Only a
>> complete clean and rebuild will do that.
>
> Things can be duped. (even if you just change the file manually) but I need
> something in place that will allow me to install patches without having to do
> a make world. 'make world' will work (and we probably should make it install
> the version stamp anyhow) but I won't be using (wasn't planning to) make
> world to install a patch to kappa. In that case it's useful information to
> know that the current system is installed as revision 24550:24660 because
> that indicates I've got a mismatch in there. 24550M would also be useful to
> know because that would indicate somewhere there is a locall modified file
> (which shouldn't happen at CADC). This is where running svnversion from the
> top level directory reall helps. Having the install target install the most
> recent version information will help (especially now that we have shard
> libraries) so long as the user understands that to trust the version number
> they need to have installed the version they just updated.
>
> I will modify the starversion command to pick up the file in manifests.
Tim,
OK, I've got some modifications to starconf and automake that add a new
target to all the installs. Looking at all this in action the problems I
see are:
1) svnversion can take a while to run on the whole tree (first time
anyway)
2) it's messy locating the head of the source tree.
2) is the more major problem.
What I've done for the moment is introduce a environment variable
"STAR_SOURCE_ROOT_DIR", that you point at the head of your source tree.
This will be spotted during configure and provided there's an svnversion
on the system each package install will then update starlink.version, as
you want. How does having to define this before a build tree will start
recording this information sound (i.e. the whole system is off by
default, solving 1) and 2) )?
Peter.
|