[m-dev.] Libraries Idea

[Warwick Harvey]

Fergus wrote:
> On 16-Sep-1999, Ralph Becket <rbeck at microsoft.com> wrote:
> > I've had an idea about how mmake etc. might simplify the installation
> > and use of libraries.  Basically, the idea is to optionally make
> > library module compilation lazy.  The programmer would supply mmake
> > with a search path where various source and object files etc. could be
> > found.  If a required object (or whatever) file in one of these
> > directories is found to be out of date then the compiler would be
> > invoked *in that directory*.  Such a scheme would allow for on-demand
> > compilation of the standard library in the various grades rather than
> > requiring the marathon installfest that is the case at present.  It
> > would also greatly ease the process of getting the compiler to
> > recognise new libraries, and work in multiple grades.
> 
> I think Richard O'Keefe suggested something along those lines in mail to
> mercury-users.  I think this is a fine idea, so long as it is not
> the default.
> 
> Warwick has some changes to improve the support for building and installing 
> ibraries in multiple grades.  However, they have not yet been committed.
> Warwick, what's the current status of those changes?

Only the use of libraries installed in alternative locations is committed.  
I have an old prototype of the installation side of things, but that was 
developed in conjunction with an earlier attempt at the "use" side which was 
done "the wrong way".  For any future version of the installation side, I 
would probably start from scratch, rather than modifying the prototype 
(though obviously I'd use some of the ideas from it).  I haven't done any 
work on this, and am unlikely to have time before late November at the 
earliest (I leave for a month overseas in a few weeks, and when I come back 
Bart will be here, so working with him will be #1 priority).  If somebody 
else wants to work on it, I'd be happy to discuss it with them though.

With regard to Ralph's proposal, I have a number of concerns, which I think 
should be addressed before taking things much further.

1.  If the idea is to build grades lazily, and a library is missing in the 
grade being used, how does the system know in which directory in the search 
path the library belongs?

2.  Assuming the system knows in which directory the library should go, how 
does it know where to find the source for that library?

3.  On a multi-user / shared installation, how does one assure that file 
ownership and permissions are appropriate so that (a) anybody can cause a 
new grade to be installed, (b) a grade installed by one user can be used by 
another, and (c) no user can do malicious things to the installation.  To a 
lesser extent, one might also want to think about whether a user can 
intentionally (or even unintentionally) fill up the disk with a plethora of 
useless grades.


I use quite a few different grades in my work, and a couple of user-built 
libraries.  I often get link errors because one or more are not built in the 
grade I'm using.  But I keep the installed version of the compiler and the 
extra libraries in a built state, and whenever I need a new grade of them, I 
simply go to the appropriate directory and type

nice +19 mmake install MMAKEFLAGS=-j2 LIBGRADES='<list of grades I want>'

and that seems to work fine, and doesn't seem *too* much trouble (to me).  
(Of course it's not so easy for the other users, since they have to get me 
to do it if they have the same problem, but usually I trip over it before 
they do.)

One thing I may do at some point however is to arrange for my extra 
libraries to be built and installed at the same time the compiler is 
installed.


Anyway Ralph, if you're interested in actually trying to implement your 
idea, I'd be happy to discuss it with you.  Though before you leap into such 
a project, you might like to bear in mind that Make programming sucks.  :-)

Cheers,
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
--------------------------------------------------------------------------