[m-users.] Mercury to c# workflow?

[Julien Fischer]

Hi,

On Tue, 18 Jan 2022, David Epstein wrote:

> I'm trying to compile the example program you posted. I see you included a Makefile, but I'm not sure how to use it. I
> promise I will get better at this!
> 
> I've compiled and installed Mercury from source with the Csharp grade
> enabled. The READMEs specified that I needed a UNIX environment like
> MSYS2 to compile Mercury but not to use it. I've added C:\mercury\bin
> to my path and opened a regular command prompt. I'm following
> README.CSharp (using "mercury" instead of "mmc" as recommended on
> Windows) but it seems to still expect access to UNIX commands like
> "cp" instead of Windows commands like "copy" (see below).

When you build the system under MSYS2, it will be configured for use
under MSYS2.  You will need to make some changes to the compiler's
configuration to use it directly from the Windows command prompt.
All of the compiler's configuration settings are stored in the file:

      <install-prefix>\lib\mercury\conf\Mercury.config

where <install-prefix> is wherever Mercury was installed on your
system.  You will need to change at least the following:

1) Tell the Mercury compiler what command to use to copy files.
This is done using the option '--install-command'.
(The default value for that option is "cp", which is why it is attempting
to use that copy files.)

Adding, for example,

      --install-command copy

to the configuration file will cause it to use copy.exe instead of cp.

Aside: copy.exe is weird and there's no way to shut the messages
it prints when it copies something -- at least, there wasn't last
I looked.  When building installations for Windows, I generally just
grab a port of GNU cp for Windows (e.g. from the UnxUtils package)
and add that to Mercury's bin directory.

2. Adjust the values of the --host-env-type and --target-env-types
options from "msys" to "windows".  (They're towards the bottom
of the configuration file.)  These options have a number of effects,
including altering the way the compiler handles file paths and causing
it to emit batch file launchers for C# and Java programs instead of
shell scripts.

> The README also says that the output will be an EXE file although I
> expected a DLL file for linking to my C# code. I thought I would
> generate fuitbowl.dll and add it to my C# project along with
> mer_std.dll and then compile the C# project in Visual Studio,
> initially to a command line program and later to an Android app with a
> simple GUI.

To output a DLL you just need to build the module as a library instead
of an executable, e.g.

     $ mercury --grade csharp --make libfruitbowl

(i.e. add the "lib" prefix in front of the module target, which is what
you are missing below.)

> OUTPUT FROM A WINDOWS COMMAND PROMPT
> D:\Documents\Programming\CSharp\MercuryExamples\fruitbowl>mercury --grade csharp --make fruitbowl
> Making Mercury\int3s\fruitbowl.int3
> 'cp' is not recognized as an internal or external command,
> operable program or batch file.
> Making Mercury\ints\fruitbowl.int
> 'cp' is not recognized as an internal or external command,
> operable program or batch file.
> 'cp' is not recognized as an internal or external command,
> operable program or batch file.
> Making Mercury\css\fruitbowl.cs
> Making fruitbowl.exe
> 'csc' is not recognized as an internal or external command,

Your final problem here appears to be that Mercury cannot find
the C# compiler; is it in your PATH?  You may want to check
the output of:

     mercury --output-csharp-compiler

and see it makes sense.  It may be that it was written to the
configuration file (option: --csharp-compiler) with MSYS style paths or
something and may need to be adjusted.

Julien.