On Wed, 20 Jun 2007, Peter W. Draper wrote:
> On Wed, 20 Jun 2007, Peter W. Draper wrote:
>
>> 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) )?
>
> Actually since I'm on holiday from tonight until next week, I've gone ahead
> and committed those changes, along with the corresponding ones for "make
> world". I'll remove/amend them next week, if needed.
I've added a note to the README about these changes, just so they are
documented in the system somewhere.
What really needs to be done is an overhaul of SSN/78 to remove all the
CVS-specific information (and replace with subversion equivalents, maybe,
but perhaps just dumping it would be more maintainable), but that looks
like quite a large job...
Peter.
|