[m-dev.] Libraries Idea

[Warwick Harvey]

Ralph Becket <rbeck at microsoft.com> wrote:
[...]
> 2. Users of sys-admin installed versions that also want to employ
> private (versions of) libraries.
> 
> 3. Users who install and administer their own versions (e.g. on home
> machines).

[...]

> However, in cases 2 and 3 you want to make it as easy as possible for
> users to develop private library suites, and this is what I was trying
> to get at in the first place.

Sorry, I misinterpreted your original post then.

I had composed a reasonably detailed reply to this mail about how to modify 
the compiler to make it easy to install private library suites (something 
I've intended to do for ages but never found the time), but then figured 
it'd probably take you longer to figure out what I was on about than it 
would take me to finish the job.

Anyway, I have a rough cut which seems to work.  You just need to specify in 
your Mmakefile where you want to install the library, and which grades you 
wish to install it in:

	INSTALL_PREFIX = ...
	LIBGRADES = ...

Then you just do a `mmake lib<foo>.install' and it will do the rest.

It needs some more polishing and some documentation, etc., but I'll try to 
find some time one night this week to finish it off.

One issue is how much of the Mercury installation hierarchy should be 
mimicked.  E.g. if you set the installation prefix to be, say, 
`/my/install/dir', should the `lib', `ints' and `modules' directories go in 
that directory, or should they be in a `lib/mercury' subdirectory?

If you've got a directory just for Mercury libraries and nothing else, the 
two extra levels of nesting seem a bit silly, but if you're installing into 
a more general location (e.g. /usr/contrib), then you probably want them.  
Or if this stuff is generalised a bit further so that executable files, 
documentation, etc. can also be installed, then you probably want them.

The stuff in the current version of Mercury for *using* alternative 
libraries does not assume the libraries reside in a `lib/mercury' directory, 
so at the moment one would have to specify that manually if that were the 
decision.  In that case, it's probably worth changing the behaviour of the 
"use" stuff to include the `lib/mercury' component --- it shouldn't be too 
hard to migrate.

> What I would like to do is to say something like the following to
> mmake:
> 
> - here is a list of places where you can look for compiled libraries
> in various grades (e.g. installed, private, friends', ...);

This already works: see the user's guide (Libraries -> Supporting multiple 
grades and architectures) from a reasonably recent (last couple of months) 
version of Mercury.

> - here is a list of places where you can find source code;
> 
> - this is the place where I keep my own compiled libraries;
> 
> - if you can't find a compiled version of a library, but can find the
> source code for it, then compile the source code in the appropriate
> grade and install it in my library tree.

This should be much easier once I've finished my library install changes.

> So, the places where compiled libraries are put all have a common
> structure (a la /usr/local/mercury/lib) which would be constructed
> and updated as necessary when mmake compiles a new library.

What would be really cool (and I'd find damned useful) is if the system 
detected not just missing libraries, but out-of-date ones.  This bites me 
all the time.  I don't know how practical doing this would be though.

> I'd offer to have a go at this, but I don't want to tread on anybody's
> toes!

Well, once I've finished the library install stuff, as far as I'm concerned 
you're welcome to do anything you like!

Warwick

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------