[m-dev.] Mercury build size and library versioning

[Ralph Becket]

Peter Hawkins, Wednesday, 14 July 2004:
> building the following grades to include in the package:
> asm_fast.gc
> asm_fast.gc.profdeep
> asm_fast.gc.memprof
> asm_fast.gc.prof
> asm_fast.gc.tr
> asm_fast.gc.tr.debug
> asm_fast.gc.prof.tr (I added this one since I use it a lot myself)
> hlc.gc
> hlc.par.gc
> 
> Can I safely omit any of these? I suspect profdeep can go until the deep 
> profiler has been fixed, any others?

You can safely omit all but one of them!

I get by quite happily with just two: asm_fast.gc.tr.debug for debugging
and either asm_fast.gc or hlc.gc (add .tr to those grades if you need
trailing.)

> My other query is to do with dynamic linking and mercury grades. The other 
> obvious place to reduce space usage would be to force dynamic linking by 
> default.

IIRC, there is a performance penalty associated with dynamic linking
which is why we don't enable it by default.

> It appears that all of the dynamic libraries for mercury grades are 
> unversioned. Unfortunately, this makes it impossible to package dynamically 
> linked applications, since it is not possible to correctly declare a 
> dependency on an unversioned library, leading to problems when the libraries 
> are changed.
> 
> What are the chances like of introducing properly versioned libraries in the 
> next release (and ensuring binary compatibility within major library 
> versions)?

We'll look into it - thanks for pointing that out.

-- Ralph
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------