[m-dev.] Determining which grades an installed Mercury compiler supports

[Julien Fischer]

Hi Keri,

On Wed, 18 Jul 2018, Keri Harris wrote:

> I've run into a couple of interesting issues in how Mercury determines which 
> grades it supports. For C grades, the compiler checks for the existence of 
> mercury/modules/$grade/mer_std.c,

mer_std.init.

> for non-C grades just the mercury/modules/$grade directory.

Yes.

> The erlang grade can have problems with this approach since init files can be 
> installed into the mercury/module/erlang directory. In particular, a problem 
> can arise when a 3rd-party library installs an erlang init file, and then 
> Mercury is later reinstalled without support for the erlang grade; these 
> residual 3rd-party init files can confuse Mercury into believing that it 
> still does support the erlang grade. The following sequence of events leads 
> to this:

...

The erlang backend used to not use .init files; since it does now we can
just update the compiler to check for the presence mer_std.init as per
the C grades.

> The modules/java and modules/csharp directories seem immune to the above 
> problem as these grades don't appear to ever create init files. However, even 
> these grades can cause problems with package managers whenever multiple 
> packages share the same MERCURY_LIBDIR location. The modules/java and 
> modules/csharp directories will then be 'owned' by multiple packages, and 
> package managers will tend to delete empty directories belonging to a package 
> whenever that package is uninstalled. Thus it's possible for the mercury 
> compiler to lose track of which grades it supports. For example on Gentoo 
> Linux:

For the C# and Java grades, we should look for something more definite;
the presence of mercury/lib/csharp/mer_std.dll and
mercury/lib/java/mer_std.jar for example.

Julien.