[m-dev.] Proposal: Improve specifying Mercury install paths

Julien Fischer jfischer at opturion.com
Sun Apr 5 15:27:51 AEST 2020

Hi Keri,

(Paul, I've copied you in on this in case any of it affects how you
build the Debian packages.)

On Wed, 1 Apr 2020, Keri Harris wrote:

> On 29/03/2020 01:41, Julien Fischer wrote:

>> Allowing that may have been the original intent when the library
>> installation directory was designed, however that was well before
>> Linux distributions started using /usr/lib64 etc.
>> At this point, I think it may be simpler to achieve something close
>> to what you want by making it possible to specify alternative
>> installation directories for the executables ({prefix}/bin) and
>> documentation ({prefix}/share) instead.  (Autoconf already provides
>> --bindir etc, we just don't use them.)
>> In that case I would suggest setting the installation prefix for the
>> rest of the system to /usr/lib64/mercury or /usr/lib/mercury and
>> living with the fact that there will be a few extra layers of
>> subdirectories (i.e. lib/mercury) beneath that.
>> The library files being installed under $prefix/lib/mercury is hard
>> coded throughout a good part of the system and changing that would be
>> a reasonable chunk of work.  (For not much benefit IMO.)
> I've attached a patch that modifies the Mercury scripts to respect --
> bindir. Note that any time @bindir@ is occurs both @prefix@ and
> @exec_prefix@ need to also be present in the script. e.g:
>    prefix=@prefix@
>    exec_prefix=@exec_prefix@
>    MERCURY_COMPILER=${MERCURY_COMPILER-"@bindir@/mercury_compile"}
> Running configure without a --bindir arg will set the following default
> values:
>    $ ./configure
>    prefix = ...
>    exec_prefix=${prefix}
>    MERCURY_COMPILER=${MERCURY_COMPILER-"${exec_prefix}/bin/mercury_compile"}
> Running with a --bindir arg bypasses $prefix and $exec_prefix as we
> would expect:
>    $ ./configure --bindir=/usr/bin
>    prefix = ...
>    exec_prefix=${prefix}
>    MERCURY_COMPILER=${MERCURY_COMPILER-"/usr/bin/mercury_compile"}

That should be fine; I'll try your patch out.  Mercury and autoconf are
something of an imperfect fit anyway.  So far as Mercury is concerned
the supported configuration options for setting installation directories
will now be:

     + whatever ones are require for setting documentation directories.

(The others, such as --exec-prefix, don't really make sense for Mercury.)

We'll need to document all this somewhere, probably in .INSTALL.in.
(Unfortunately, it doesn't seem possible to change the usage message
for the configure script.)

> Other Mercury install directories already support various autoconf
> directories like @docdir@, @infodir etc. While having extra layers of
> subdirectories is not a prefect solution, it's probably satisfactory
> for most installations.
> Changing the meaning of mmc --install-prefix within the mercury
> compiler is another possible solution. It also isn't too complicated -
> just compiler/file_util.m & compiler/make.program_target.m would need
> to change.

Changing the behaviour of --install-prefix is also going to potentially
break the build systems of software written in Mercury.  (That will
certainly be the case for the Mercury software developed by my company.)

> To date on Gentoo Linux I've been patching those files to
> replace the hard coded lib/mercury paths with multilib-aware paths. The
> obvious drawback to patching compiler .m files is that you can only do
> that after having an instance of mercury_compile already built.

The other downside of that is that the behaviour of the Gentoo packages
will differ from the documented behaviour in the user guide etc.  (Or do
you patch that too?)


More information about the developers mailing list