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

[Zoltan Somogyi]

On 18-Nov-2008, Paul Bone <pbone at csse.unimelb.edu.au> wrote:
> 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.

Mdb is a 200 line shell script. The real code of the debugger is in
the libraries that are linked into programs: the trace, browser and mdbcomp
libraries.

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

Only indirectly. It is what creates the mainmodulename_init.c file.

> /usr/bin/canonical_grade
> /usr/bin/info_to_mdb
>     Is this specific to the debugger?

It generates the debugger's documenation. If the debugger's documentation
is included already generated, users should not need it.

> /usr/bin/mdemangle
> /usr/bin/mercury_cleanup_install
>     What does this do?

What its name says.

> /usr/bin/mercury_compile
>     This and mmc are obvious.
> /usr/bin/mercury_profile
> /usr/bin/mercury_update_interface
>     What does this do?

Decide whether the old and new versions of the interface of a module
are the same, and if not, copy the new (whose filename ends in .tmp)
over the old. Users need it.

> /usr/bin/mgnuc
> /usr/bin/mkfifo_using_mknod
>     When is this used? Do I need it?

It is used when preparing binary distributions, which ordinary users
shouldn't need to do.

> /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?

It is used when installing the libraries in grades other than the provided,
precompiled grade. Yes, you need it.

> /usr/bin/vpath_find
>     When is this used? Do I need it?

It is used by the make file fragment that gives mmake its knowledge about
how to compile Mercury programs. mmake won't work without it in the user's
path.

> Firstly, no versioning has been done for the mercury standard library

That is not a sufficient reason, since attaching a version number is not
a tough job. What is tough is the testing that goes with a release, but the
two need not be related.

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

Have a look at the handling of binary compatibility in runtime/mercury_grade.h.

> We should only
> distribute libraries built by compilers with complete version numbers
> (not CVS or ROTD compilers).

For Debian, this may be ok, if it weren't for the fact that 0.13 is so old.

> To do this we might like to make unstable
> releases of Mercury.

We have been doing rotds almost since the start of the project.

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