[m-dev.] Other things to do before the release.

[Fergus Henderson]

On 12-Sep-1998, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> On 12-Sep-1998, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > On 10-Sep-1998, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > > - Move the following executables into a lib/bin directory so they
> > >   are not in the user's path:
> > > 	mercury_update_interface mint mkfifo_using_mknod mkinit 
> > >   (possibly more or less, this list was taken from 0.7.3).
> > 
> > `mint' should not be moved; it was intended for use by users.
> > It could be deleted, I suppose.
> 
> If intended to be used by users, it needs a man page.

Yep.  Tom, could you have a go at this sometime?
This one is not release-critical.

> > > - Possibly support use without -rpath shared libraries (install
> > >   libraries to /usr/lib and call ldconfig).
> > 
> > What's the advantage of this?
> > 
> > There are certainly disadvantages, e.g. installation would require
> > root permissions.
> 
> No it wouldn't, you can always set LD_LIBRAY_PATH.
> I didn't say *force* use of ldconfig, just support use of it.

That is good, because not all systems have ldconfig.

> Advantages:
> 	- installation can be moved without breaking existing dynamically
> 	  linked binaries
> 	  (that is, you can re-install Mercury into a different --prefix
> 	  and your old binaries will still be able to work).

Fair enough.

> 	- dynamically linked binaries can be distributed and will still
> 	  work (try running a dynamically linked binary made on
> 	  hydra with a machine that has mercury installed somewhere
> 	  *other* than
> 	  /home/mercury/public/mercury-latest/i686-pc-linux-gnu).

Well, for `mercury-latest' you shouldn't expect it to work anyway,
unless you're using exactly the same versions on both machines.

If you just use the same prefix on all machines,
e.g. the default prefix of /usr/local/mercury-<version>, then
you can transport dynamically linked binaries between those machines.

So I don't think it buys that much.  It does buy a bit, though,
so this is a nice idea for the wish list.  I don't think it is
release-critical.

One difficulty with implementing it is that the naming scheme for
libraries will probably need to change so that it includes the version
number and the grade.  Currently these are part of the directory
path rather than the file name.  A related difficulty is that
some systems don't allow `.' in the names of shared libraries
(except for shared library major & minor version numbers, which
are different from Mercury version numbers).

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.