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

[Paul Bone]

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.

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

>> 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_.  Adding extra grades from source is something that only makes
sense after you've installed from source.  Which means that you already have
cygwin, so the dependency on cygwin is a non-issue because you already have
it.  Therefore the dependency on cygwin for this feature is fine by me.  I
think I confused you (my fault) when I said "modulo the things you mentioned
above", I didn't have any specific problems with these restrictions.

Now that I understand the requirements on Windows better I acknowledge these
restrictions and agree that in practice they shouldn't be a problem.

Thanks.


-- 
Paul Bone