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

[Julien Fischer]

Hi Paul,

On Mon, 15 Sep 2014, Paul Bone wrote:

> On Mon, Sep 15, 2014 at 02:23:38PM +1000, Julien Fischer wrote:
>>
>> 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.)
>>
>
> I suggest installing the config.status file when we install Mercury and
> either manually, or using autoconf to read settings out of this file when
> the new option is used.  Or alternatively create a new file that autoconf
> can write some settings into and store just these settings that should be
> used when adding libraries in it.

We already install the config.status file (and everything necessary to
reconfigure) in <INSTALL-PREFIX>/lib/mercury/reconf.

>>>>> 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?
>
> You mention below that these kinds of changes will also affect the original
> installation.  This is a specific case of that general problem below.
>
> If Mercury was installed with only an asm_fast.gc grade, and configure
> detected a particular version of libreadline (which is used in debugging
> grades only).  Then libreadline was changed, then a debugging grade was
> installed.  It's possible that the standard library was built against one
> version of libreadline, but applications that link against it are built
> against another.
>
>>> 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.
>
> Yes, and that can still be a problem, it's not an argument against your
> proposal but just a general comment.

The major environment change that is likely to affect Mercury is the C
compiler changing (e.g. "gcc" used to be vesion 4.7 now it's version
4.9).  This is because while most libraries that Mercury depends upon
have stable (and backwards compatible) APIs, most C compilers don't have
stable (and backwards compatible) bugs!  The only thing that can be done
about this at the momet is to reconfigure the installed system (or at
least edit Mercury.config to update the C compiler type and flags).

I did make a proposal for improving all of this about a year or so ago,
but I haven't had the opportunity to implement it.

>>>
>>>>> 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.
>
> I don't understand, what is the problem here, the lack of a shell or the
> lack of cygwin.dll?

The issue is actually path translation and what happens when you call
the C function system().  The Mercury compiler calls this function on
Windows (at least) to invoke external programs such as the C compiler.
When you call system() with programs linked against cygwin.dll the
argument gets passed to sh, so using Unix style paths is fine for that.

On native Windows (i.e. not linked against cygwin.dll), the argument to a
call to system() will get passed to whatever the environment variable
COMSPEC is pointing towards.  This is typically command.exe.
command.exe does _not_ understand Unix style paths.  So if you're
building a native compiler under Cygwin, or under MSYS, tools like make
will use (and require) Unix style paths, but the programs invoked
directly by the Mercury compiler can't have them.

>>> 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.
>
> Yes.  As far as I'm aware cygwin is required for installation from source
> _at all_.

Nope, MinGW/MSYS can be used as well -- there's no need for Cygwin at
all if you don't want it.

Cheers,
Julien.