[m-rev.] for preliminary review: post-installation addition of extra library grades

[Julien Fischer]

On Mon, 15 Sep 2014, Paul Bone wrote:

> On Mon, Sep 15, 2014 at 12:39:49PM +1000, Julien Fischer wrote:
>>
>>
>> On Mon, 15 Sep 2014, Paul Bone wrote:
>>
>>>> The above causes the java and csharp grades to be added to the existing
>>>> installation.  (This is no different to what the developers of Mercury already
>>>> do in this situation except that it removes the need to edit Mmakefiles by
>>>> hand and makes the whole thing a bit more user-friendly.)
>>>>
>>>> configure.ac:
>>>> 	Add the new option.  If it is enabled then:
>>>> 	- query the installed Mercury compiler for which C compiler to use.
>>>> 	- use the install prefix of the installed compiler by default.
>>>> 	- set the set of grades to be installed to empty.
>>>
>>> What about other options that may have been specified the first time Mercury
>>> was installed.  for exmaple someone might use a prefix of /foo/bar, but a
>>> libdir of /foo/baz/lib/.  Options like this will need to be used.
>>
>> The --prefix option can be given and the new grades installed somewhere
>> else (if you really want to).  I didn't try separate library
>> installation directories (does that work anyway?), but in principle I
>> think that should work (or at least could be made to).  That said, I
>> doubt they're actually used all that often.
>>
>
> I think that you misunderstand me.  I mean a case where the original
> installation had a non-default layout and the installation of additional
> grades should use the same layout automatically, without passing new options
> to ./configure.

So long as the system can determine where the libraries are installed,
there should be no problem with non-default layouts.  (The initial
version of this change doens't support it because there isn't a
straightforward mechanism for asking the compiler what library
installation it's been pointed at, so it will only work with the default
layout.)

>>> Some things such as versions of C libraries that are installed should
>>> however be re-detected.
>>
>> The existing compiler should be queried for what they are.  Since the
>> installed config files won't be re-written by this, what's in them,
>> rather than the results of the configure for extra grade installation,
>> will be used when actually using the new grades.
>
> That may lead to problems in some situtations.

Such as?

> But I think the more general problem is that when you use Mercury you
> may need different options than when you installed it.  In other
> words, the environment can change after installation that may affect
> the compilation of Mercury programs.

Environment changes that do that will also affect the original
installation, in which case installing extra grades is the least of your
problems.

>
>>> The rest seems okay modulo the things you mentioned above.
>>
>> Windows, except for Cygwin, is not going to work for the moment.  Native
>> Windows lacks a suitable shell for running configure scripts and MSYS
>> has a bunch of path translation issues.
>
> Yes, presumably if cygwin is installed, as it (usually?) is for
> installation, then that won't be a problem.

When I say Cygwin here I mean the Mercury port to Cygwin (i.e. where
executables are linked against cygwin.dll).  For most purposes, that
behaves pretty much like Unix as far as Mercury is concerned.  For other
Windows ports that is not the case.

> AIUI the only cases where this is a problem is if cygwin has been
> uninstalled or the user installed from a binary distribution and
> didn't require cygwin in the first place.

The requirements for extra grade installation are no different that of a
normal installation; on Windows you will require a Unix style
environment.  Lifting that restriction would be a huge amount of work
for not much return IMO.

Cheers,
Julien.