[m-dev.] issues with installing libraries

[Zoltan Somogyi]

On Sun, 15 Sep 2024 14:20:13 +1000, Julien Fischer <jfischer at opturion.com> wrote:
> I don't have anything particularly illuminating to add.  I spent a bit
> of time last weekend
> trying to understand how we arrived at the current library
> installation structure only to
> arrive at the conclusion that most of it was a fait accompli before it
> even arrived in version
> control.  (Support for user libraries with mmake was added ~1999, the
> structure they
> use mimics that used for the Mercury libraries themselves. The
> structure used for the
> Mercury libraries was mostly in place around 1995.)

Agreed.

> In terms of library installation structure, I think there are few
> principles we have been
> trying to / should adhere to:
> 
> 1. A library installation should be usable using (a) mmake, (b) mmc --make and
>    (c) mmc invoked on a single module regardless of which build system is used
>    to build it.  (Obviously, libraries installed by mmc --make cannot
> have .trans_opt
>    files, but the compiler can already handle the absence of those.)

Agreed.

> 2. Users should not have to understand the structure of a library installation.
>     If a user is using a Mercury library via the Mercury compiler,
> then the compiler
>     understands this structure and all the user should need to do is
> point it to the
>     correct library and installation directory (e.g. using the --ml
> and --mld options
>     or the equivalent mmake variables.)
>     If the user is using a Mercury library not via the Mercury
> compiler (e.g. a C++
>     program that links against Mercury libraries or refers to Mercury
> headers), then
>     the correct way is to get the Mercury compiler to tell the user
> what information
>     they require.

Agreed.

> We already have a bunch of options,
> --output-cflags, --output-c-include-dir-flags,
>    --output-grade-defines, that do exactly this.

I am not sure that these are adequate for the task, but if
they aren't, it shouldn't be too hard to fix them.

> We should add something to compiler/notes documenting whatever the
> library installation
> structure is / becomes.  (Although I am fairly certain you are
> intending to do that anyway.)

Agreed on both counts.

Zoltan.