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

[Paul Bone]

On Mon, Sep 15, 2014 at 04:05:24PM +1000, Julien Fischer wrote:
> Hi Paul,
>
>>>> 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.
>

I agree, and AFAIK updating Mercury.config should be sufficient.

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

Okay, that makes sense.

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

Sorry, what I ment to say was a unix compatibility layer, in particular
something to run configure and mmake.


-- 
Paul Bone