Release changes

1. have lib*.so have the name of the release as part of its file name
2. have *.so have the name of the release as part of its file name
3. DynamicLoader should enforce that release names match
4. Changes to M.tail to get release name from C3LIB, but for current always determine actual current version

Code finished on 2004/11/19 by cdj

Building release patches

1. create area
2. create a pkg_version_patch file
3. make actual source directories and binaries immutable (i.e. let the soft-links changes but not the stuff they are linked with). This avoids accidently breaking the 'master' release
4. set soft-links to source and binaries, for lib*.so_* and .so_ make sure postfix is new release name [do not softlink suez.exe* since need a new one for each release]
5. build dependency files (and only them)
6. replace source links with new source for packages to be updated, do this using 'cvs trick' of checking out old version and then 'update' to new version
7. for every package do 'gmake -q' to see if package wants to be updated, if so remove all links to binaries for that package (a 'gmake clean_binaries' would be useful although 'gmake clean' would work, but would cause us to re-run dependency finding) NOTE: packages from 6) will automatically fail the no change test
8. delete libDynamicLoader.a since needs to know release name
9. rerun build normally

NOTE: potential problem with packages that modify other packages (e.g. MakeMasses puts its autogenerated masses.h file into Experiment package) -- ChrisDJones - 17 Nov 2004