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.
Cheers,
Peter.
|