[m-users.] Installing a subset of built grades

[Mark Green]

Hi,

Further to the previous message, I tried building without the Erlang grade and after using the Visual Studio Command Prompt to start MSYS, but the IL grade still failed - it finds CSC ok, but again uses paths relative to "." to provide paths to CSC, so CSC starts trying to resolve them relative to the directory where msys.bat is. Which is especially annoying since I made sure to CD the Windows command prompt to the Mercury source directory before starting msys :(

Mark Green
mgreen at brookes.ac.uk



On 29 May 2013, at 22:03, Mark Green <mgreen at brookes.ac.uk> wrote:

> Hi,
> 
> Thanks for your reply. The Erlang grade error turns out to be because it calls the Erlang compiler? with the parameters "-I ./mercury/erls -O ./mercury/beams" and . isn't where it expects it to be.  The problem is, I don't really think that this is easily fixable by setting the PATH up because Erlang will not look on the PATH for relative input and output directories.
> 
> On another note, is there anything close to an IDE for Mercury? I'm having a play with making custom interfaces for IntelliJ Platform and wondering if it could be used to do something, although its parser generator may not be sophisticated enough to do the operator syntax without colossal problems.
> 
> Mark
> 
> 
> 
> On 29 May 2013 14:48, Julien Fischer <jfischer at opturion.com> wrote:
> 
> Hi,
> 
> 
> On Wed, 29 May 2013, Mark Green wrote:
> 
> Yes, I do mean the non-C grades. Specifically, the csharp grade seemed
> to fail due to looking for files in the Windows execution path for the
> MingW shell rather than in the active directory within MingW. I tried
> building a new shortcut to start the MingW shell in the Mercury
> srcdist directory but so far I haven't been able to test it because of
> the long time taken to get to the csharp grade.
> 
> One of the issues here is that although you are building Mercury inside
> the MSYS shell, when the Mercury compiler itself starts up an external
> process via a call to system() it does  it via what ever command
> interpreter the environment variable COMSPEC is pointing to; that's
> typically cmd.exe**.  IIRC, the child cmd.exe instance should inherit
> the environment from the MSYS shell, but it's rather picky about
> how the directory paths are specified.  (In practice none of this -- or
> indeed what follows -- seems to be terribly consistent between different
> versions of Windows either.)
> 
> ** this is not so strange, the intent of building things with MinGW
> is to produce a compiler that runs natively on Windows.
> 
> One way around all this is to invoke the ``Visual Studio Command
> Prompt'' shortcut (or whatever it's called, the name varies between
> different versions of Windows and / or Visual Studio) and then start MSYS
> from within that cmd.exe instance (i.e. run C:\MinGW\msys\1.0\msys.bat).
> I think things should be okay then; provided you can correctly invoke
> csc from the MSYS shell.  (I'll check this tomorrow, I don't have access
> to a Windows machine at the moment.)
> 
> [We should probably have a configure test that checks that the C#
> compiler can be invoked correctly via a call to system() (or whatever is
> used): I'll look into adding one.]
> 
> Also, it is crucial that when specifying the installation directory for
> Mercury, with configure's `--prefix' option, that it be a Windows style
> path rather than a Unix style one.
> 
> 
> The Erlang grade fails with a file not found error when building the
> first beam file. I tried enabling verbose-commands as before; I don't
> have the log to hand right now, though.
> 
> It's probably a similar issue to the above (the same would apply to the
> Java grade when building with MinGW / MSYS).
> 
> 
> Just to clarify I am talking about restarting an install that failed
> midway through, not one that was configured with a smaller number of
> grades. I ran configure and make with all grades enabled but make
> install failed after installing the C grades. It's really awkward if I
> really have to just sit and wait while asm_fast.gc etc are built only
> for the installer to report that all the files are unchanged and just
> delete all the work it did in the last two hours :(
> 
> Restarting the installation for a subset of grades was discussed
> elsewhere in this thread.  One thing I think we can do here is
> make configure do some stronger checks that everything is working
> properly, *before* everything is compiled.
> 
> Cheers,
> Julien.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20130531/99562335/attachment.html>