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

[Paul Bone]

On Mon, Sep 15, 2014 at 12:39:49PM +1000, Julien Fischer wrote:
>
>
> On Mon, 15 Sep 2014, Paul Bone wrote:
>
>> On Tue, Sep 09, 2014 at 01:57:39PM +1000, Julien Fischer wrote:
>>>
>>> For preliminary review:
>>>
>>> (This almost certainly does not work on Windows at the moment.  Also,
>>> attempting to add extra grades to a cross compiler probably won't work
>>> either.)
>>>
>>> ---------------------------
>>>
>>> Support post-installation addition of extra library grades.
>>>
>>> A feature that has often been requested is the ability to add extra library
>>> grades to an existing Mercury installation without requiring a re-install of
>>> the entire system.  In the past doing this has been awkward because the set of
>>> library grades is hardcoded into various configuration files.  This is no
>>> longer true for mmc --make, which now detects the set of installed library
>>> grades at runtime.  (It is still true for mmake, but that probably doesn't matter.)
>>>
>>> This change adds a new option to configure script,
>>> --enable-extra-grade-install.  When invoked with this option, the configure
>>> script will set up the source tree to build and install only additional library
>>> grades, not the entire system.  An example of the process is:
>>>
>>>    $ ./configure --enable-extra-grade-install
>>>    $ mmake LIBGRADES="java csharp" install
>>>
>>> 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.

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

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

> I don't intend to support extra grade installation for cross compilers
> for the time being.
>

I think that's fine.


-- 
Paul Bone