[m-dev.] Mixing grades and package size

[Zoltan Somogyi]

On 14-Sep-2005, Peter Hawkins <peter at hawkins.emu.id.au> wrote:
> Under what circumstances is it legitimate to link mercury code compiled
> in different grades together?

If a user asks that question, the answer is "never". If a developer asks,
the answer is "almost never, and so far we haven't found the exceptions
worth the bothering with". Whether the size of packages issue you raise
is a counterexample depends on what value you place on small downloads.

> For example, is it legitimate to link code compiled in asm_fast.gc and
> asm_fast.gc.debug grades together? How does this differ from compiling
> some code with --trace deep in asm_fast.gc together with other code with
> --trace none?

It differs precisely because in debug grades, you get a *guarantee* about
everything else in your program also being compiled with debugging enabled.
Some features of the debugger, e.g. I/O tabling, depend on that guarantee.

> Do the libmer_browser, libmer_trace and libmer_mdbcomp libraries
> actually do anything meaningful in a non-debugging grade?

Yes. You can't do without them if a program in asm_fast.gc has some modules
compiled with --trace deep.

> Could they be
> shared between debugging and non-debugging grades?

With some work, yes, but only at the cost of some complications. You'd have
to provide a mechanism to "lie" about the grade (e.g. say a module was compiled
with deep profiling, but don't do the deep profiling transformation on its
code), and then prove that the lie is a safe one. It is the latter part
that is difficult, especially since you'd need to make sure our testing setup
tested the safety of these lies frequently. We didn't think duplicating those
libraries was a big enough problem to be worth those complications.

> I've split the debian packaging up into per-grade packages in order to
> shrink the minimum download size.

Thanks.

> Perhaps there are also ways of shrinking the layout
> structures in the debugging grades?

No. I have explored ways of shrinking the space overhead of debugging in
both the .o and the .c files, and all such opportunities have already been
exploited. I am pretty sure no significant opportunities are left.

Zoltan.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------