[m-dev.] Libraries Idea

Warwick Harvey wharvey at cs.monash.edu.au
Mon Sep 27 19:25:52 AEST 1999

Fergus wrote:
> On 27-Sep-1999, Warwick Harvey <wharvey at cs.monash.edu.au> wrote:
> > 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.
> I think that generalizing it so that executable files and documentation
> can be installed would be a good idea, so we should plan for that.
> This suggests that we should append /lib/mercury to the user-specified
> prefix.

That was my feeling.  I was also thinking I should try to change the 
standard library's Mmakefile to use the new method.  This would seem to be a 
good test, and would make sure there were appropriate hooks, etc. for 
putting in extra things and overriding others, but I must confess I'm a 
little bit daunted by the prospect.  :-)

> However, since it is easy to do, I suggest implementing it so that the user
> can specify either, e.g. by using default values of say
> 	INSTALL_PREFIX=/usr/local/mercury-$(VERSION)
> as is currently done in Mmake.common.in (although that uses the name

Yes, the way I've done it so far is just to move these definitions (plus 
appropriate others) from Mmake.common.in to scripts/Mmake.vars.in, so the 
default will be the same place as the standard libraries, and the user can 
specify INSTALL_LIBDIR instead.  If you think it worthwhile, I should be 
able to add the INSTALL_LIB_PREFIX synonym without too much trouble --- 
though if you think it's not worth documenting, I'm not convinced it's worth 
introducing.  :-)


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

More information about the developers mailing list