[m-dev.] Binaries to install in Mercury's debian package.

[Paul Bone]

Hi,

I've been creating a set of Debian packages for Mercury.  One of these
is mercury-bin, which should contain the binaries that most Mercury
users will use (ie the compiler and mmake).  mdb, mprof, mdprof_cgi
should all be put into separate packages.

My first cut of these mercury packages provides libraries for
asm_fast.gc and allows users to create programs that statically link
against these libraries.  The rationale for this is provided below.

In the mercury-bin package, which programs are strictly needed, and
which are intended for users (ie should go in /usr/bin) and which are
intended to be called by other programs (ie should go in
/usr/libexec/mercury/).

So far I'm including the following binaries in these locations.  In some
cases I have no idea what the binary/script is supposed to do.

/usr/bin/c2init
    Do users ever invoke this?
/usr/bin/canonical_grade
/usr/bin/info_to_mdb
    Is this specific to the debugger?
/usr/bin/mdemangle
/usr/bin/mercury_cleanup_install
    What does this do?
/usr/bin/mercury_compile
    This and mmc are obvious.
/usr/bin/mercury_profile
/usr/bin/mercury_update_interface
    What does this do?
/usr/bin/mgnuc
/usr/bin/mkfifo_using_mknod
    When is this used? Do I need it?
/usr/bin/mkinit
/usr/bin/ml
/usr/bin/mmake
/usr/bin/mmc
/usr/bin/prepare_tmp_dir_fixed_part
    When is this used? Do I need it?
/usr/bin/vpath_find
    When is this used? Do I need it?

Thanks.


The rationale for disabling dynamic linking
-------------------------------------------

Firstly, no versioning has been done for the mercury standard library
and dynamic linking requires versioning, such that a program can be
dynamically linked to different versions of the standard library that do
not break compatibility, but will not be linked against different major
versions.  And that different major versions of a library may be
installed at once.  I'd like to begin versioning the standard library so
in the future packages, binary and source distributions may be used
easily without worrying about breaking compatibility.

Secondly, Different versions of the Mercury compiler can create binary
incompatible objects.  The version of a compiled library (part of the
.so's file name) depends on both the version of the library's source and
the version of the compiler used to compile it.  We should only
distribute libraries built by compilers with complete version numbers
(not CVS or ROTD compilers).  To do this we might like to make unstable
releases of Mercury.

If anyone has any ideas about how to achieve these things, or believes
I've missed anything please let me know.

Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/developers/attachments/20081118/d4933a97/attachment.sig>