mirror of
https://github.com/Mercury-Language/mercury.git
synced 2025-12-13 12:53:53 +00:00
Estimated hours taken: 8
Branches: main
Optionally generate strongly named assemblies on the IL backend.
Strongly named assemblies are required by some aspects of the .NET
framework. For example, when creating COM+ components.
We use the fact that you are allowed use the same key pair to sign more
then one assembly. The key pair we use is the one used to sign the
mercury std library. This allows us to place the correct public key
token in the `.assembly extern' reference.
README.DotNet:
Document how to generate a strongly named assembly.
compiler/mlds_to_csharp.m:
compiler/mlds_to_mcpp.m:
If --sign-assembly is enabled output a custom attribute which
references the strong name key file `mercury.sn'.
compiler/mlds_to_il.m:
If --sign-assembly is enabled add the correct decls to all the
`.assembly extern' declarations.
compiler/modules.m:
If --sign-assembly we need to generate a dependency between the IL
file and the strong name key file `mercury.sn', also add the
variable ILASM_KEYFLAG-<module> so that we add the option to sign
the assembly with the key file `mercury.sn'.
compiler/options.m:
Add --sign-assembly.
library/Mmakefile:
Install the library strong name file as `mercury.sn' in the dll
install directory.
scripts/Mmake.rules:
Add a rule to copy mercury.sn into the local subdirectory. This is
needed so that cpp and csharp modules can reference this file.
scripts/Mmake.vars.in:
Add the ILASM_KEYFLAG variables.
161 lines
5.9 KiB
Plaintext
161 lines
5.9 KiB
Plaintext
-----------------------------------------------------------------------------
|
|
|
|
INTRODUCTION
|
|
|
|
This release of Mercury contains an incomplete port to the Microsoft.NET
|
|
Common Language Runtime (CLR). This port is very new, and the target
|
|
platform is still in beta, so there are many unimplemented features.
|
|
|
|
In addition the port is currently targetted at .NET Beta 2 SDK.
|
|
|
|
The Mercury compiler will generate code in Microsoft's Intermediate
|
|
Language (IL) that can be assembled into bytecode suitable for running
|
|
in the .NET runtime system. In addition, a small part of the Mercury library
|
|
has been ported to use the .NET Frameworks.
|
|
|
|
In order to try this system you will need
|
|
|
|
- The Microsoft .NET Framework SDK Beta 2, see
|
|
<http://msdn.microsoft.com/net/>
|
|
to download. If you are an MSDN Universal subscriber you can
|
|
also order CDs as part of your subscription.
|
|
|
|
- A windows system suitable for development with Microsoft .NET
|
|
(Windows 2000 is the most likely). Microsoft advises not to
|
|
install the SDK onto a production machine. Consider using a
|
|
separate boot partition, or a virtual environment such as
|
|
VMWare (www.vmware.com).
|
|
|
|
- Cygwin (see README.MS-Windows for how to install).
|
|
The Mercury compiler still runs as a native compiler, built
|
|
with gcc by default -- although see README.MS-VisualC for how
|
|
to build with VC++ if you wish).
|
|
Mercury still relies upon the Cygwin environment for
|
|
development environment tools such as `mmake'.
|
|
|
|
- If you have installed the .NET Beta2 SDK as part of Visual
|
|
Studio .NET Beta 2, you will need to put the Visual Studio 7.0
|
|
binaries in your path, and set appropriate environment
|
|
variables. The easiest way to do this is to put the line
|
|
|
|
call "C:\Program Files\Microsoft Visual Studio.NET\Common7\Tools\vsvars32.bat"
|
|
|
|
into your cygwin.bat file (installed on the desktop by cygwin),
|
|
after the line that says @echo off.
|
|
Substitute your Visual Studio installation path for the default path
|
|
given here.
|
|
|
|
- The Mercury distribution -- installed as usual. Make sure
|
|
the installation is run after the .NET SDK is installed (run
|
|
it again if necessary) so that the configuration scripts
|
|
detect the installation path of the SDK. If `configure' finds
|
|
`ilasm' then this has been successful. You can install
|
|
from the binary distribution, but you will also need the source
|
|
distribution to install the libraries for .NET (see below).
|
|
|
|
If you're reading this file from somewhere other than the
|
|
Mercury distribution, try the Mercury homepage at
|
|
<http://www.cs.mu.oz.au/mercury/>
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
THE ILC GRADE
|
|
|
|
The Mercury compiler currently supports the grade 'ilc' to target the
|
|
Microsoft.NET CLR. Support for building and installation of this grade
|
|
is still somewhat rudimentary.
|
|
|
|
To run a Mercury program using the ilc grade, you need to build the
|
|
library and runtime in the ilc grade, using the Mercury source distribution.
|
|
If configure finds the .NET SDK installed on your machine, the ilc grade
|
|
will be added to the list of default grades to be installed, so simply
|
|
running
|
|
mmake install
|
|
from the Mercury source distribution will install the ilc grade.
|
|
|
|
You can now build programs such as hello.m or eliza.m in the samples
|
|
directory.
|
|
|
|
cd samples
|
|
mmake hello.depend GRADE=ilc
|
|
mmake hello GRADE=ilc
|
|
|
|
You can also set the grade in an Mmakefile by adding the line
|
|
GRADE=ilc
|
|
|
|
For for single file programs, try:
|
|
|
|
mmc --grade ilc hello.m
|
|
|
|
Now you can run hello
|
|
|
|
./hello.exe
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
USING DOTNET
|
|
|
|
The Mercury standard library has not been ported to .NET yet, only a few
|
|
important predicates have been implemented. Unimplemented predicates
|
|
will issue a message saying "Unimplemented: foreign code for this
|
|
function".
|
|
|
|
If you find missing functionality, you can interface to the .NET
|
|
Frameworks using C# and Mercury's foreign language interface.
|
|
|
|
For example:
|
|
|
|
:- pred to_string(T::in, string::out) is det.
|
|
:- pragma foreign_proc("C#", to_string(T::in, Str::out), [],
|
|
"{
|
|
Str = T.ToString();
|
|
}").
|
|
|
|
The implementation will put this C# in a separate file, which will be
|
|
compiled with Microsoft's C# compiler. Mmake will automatically
|
|
generate dependencies for this file and invoke the C# compiler with the
|
|
appropriate options.
|
|
|
|
You can also use the C# interface to interface with any .NET language
|
|
(Implementations have been announced or are under development for
|
|
C++, C#, Visual Basic, Cobol, Eiffel, SmallTalk, ML, Haskell, Scheme,
|
|
Python, Perl, Component Pascal and others).
|
|
|
|
Add a
|
|
MS_CSCFLAGS-<modulename>_csharp_code=/reference:<foreignmodulename>.dll
|
|
or
|
|
MS_CSCFLAGS-<modulename>_csharp_code=/addmodule:<foreignmodulename>.dll
|
|
|
|
to your Mmakefile to pass the appropriate flag to the C# compiler so
|
|
that you can reference another DLL from the C# code.
|
|
<modulename> is the name of your Mercury module, and <foreignmodulename> is
|
|
the name of the dll you want to use from Mercury via C#.
|
|
|
|
We are working on a tool that automatically generates a Mercury interface
|
|
for any .NET component, but it is not yet ready for public use.
|
|
|
|
Currently each top level Mercury module is placed into its own assembly.
|
|
For example, module.m will be placed into the assembly `module', while
|
|
module.sub.m will also be placed into the assembly `module'.
|
|
|
|
To create a strongly named assemblies in Mercury you need to pass the
|
|
--sign-assembly flag to the Mercury compiler. Note that this flag needs
|
|
to be also passed when generating the dependencies for the module being
|
|
compiled. Currently we use the same strong name as used by the mercury
|
|
standard library to sign all the Mercury modules, at a later date we
|
|
hope to lift this restriction.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
RESOURCES
|
|
|
|
You might find the following pages useful:
|
|
|
|
http://www.cs.mu.oz.au/research/mercury/dotnet.html
|
|
|
|
http://msdn.microsoft.com/net/
|
|
|
|
http://www.gotdotnet.com/
|
|
|
|
|