[m-dev.] Re: Bug#446665: mercury: should this package be removed?

[Paul Bone]

On Wed, Feb 20, 2008 at 06:43:27PM +1100, Peter Hawkins wrote:
> Hi...
> 
> On Feb 20, 2008 9:50 AM, Paul Bone <pbone at csse.unimelb.edu.au> wrote:
> > Mercury also supports 'grades', this makes it different to other
> > compliers and more interesting to package.  Each grade represents a
> > complier backend and some options.  There are two C backends, a Java
> > backend, and Erlang backend and a MSIL backend.  Options can include
> > optional garbage collection (as apposed to never reclaiming memory),
> > profiling support, debugging support and more.
> >
> > I'd like to package the library and runtime for each grade.  These can
> > all be installed concurrently and won't conflict.
> 
> There are at least two issues you may have to deal with here:
> * Mercury does not provide any guarantees about a stable library ABI,
> so you'll have difficulty packaging grades using shared libraries and
> not breaking applications when you update the libraries.

Hrm, that's true.  I know that at the top of each .m file in the
standard library a comment describes the stability of the API exported
by the library.  I've also never seen any avalible call change, or go
away.

Some more interesting grades such as deep profiling change and can
no-longer be linked with previous version of the same grade, dispite
there being no mercury library code changes, only changes in the
complier that will generate incompatible C code.  (I'm currently working
on such a change for the deep profilier).

The real solution would be to standardize the API, and version the
runtime along with libraries and programs compiled against it, which is
a problem for upstream.  Other solutions are static linking or placing
the stable version number in the package name, (like zlib1g).  Then
programs may depend on the version they where compiled/developed
against.  This could get messy but since releases are sledom it may be
ok.

> * Mercury standard libraries can be very large (tens of megabytes in
> some of the debug grades), so packaging every possible grade seems
> rather wasteful of archive space. If you ask me, you need to pick a
> small set of useful grades which cover most use cases. I'm not sure
> how many architectures Debain supports at the moment, but if you
> aren't careful you could easily consume hundreds of megabytes of
> fileserver space just on Mercury library grades (10+ architectures *
> 10s of Mb/grade * many grades).

I begun listing the grades I think would be useful to package, I found
about 6 grades, so that's not too bad.  I'll list them properly when I
build the package and check that I havn't forgotten any.

We can also reduce space by limiting the architectures that this is
avalible for, (If that's cool with Debian).  I don't expect there to be
much interest in arm, mips, mipsel or m68k.  That said, I want mipsel
packages for myself for another project :-)

Thanks.


--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------