 |
 |
On Tue, 19 Jun 2007, Peter W. Draper 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 Jenness JAC software http://www.jach.hawaii.edu/~timj