|
Hi,
I have managed to create visual studio project that
will compile and run Mono and Mint from visual C++ 7.0. I've tested it
with a few modules, and it seems to work. I haven't run the full test
suite on it yet though.
The footprint of the msvc build is small (a
subdirectory from in the "mono" directory that contains all the msvc specific
libs, includes, projects, and bin directory). The only changes to
the main project path are a variety of minor source code changes that are
necessary for cross platform compatibility.
Roughly, here are the changes to the code
base:
1. MSVC doesn't work well with the unix autoconf,
automake system (at least it's a pain in the ass). Created preconfigured
config.h and glibconfig.h files in the msvc directory.
2. MSVC doesn't link with the glib, gc, etc. dll's
that gcc cygwin uses. Luckily these were compiled with mingw, so there's
no nasty cygwin dependencies. I used dumpbin to get the exports,
converted them to .DEF files, and created MSVC import libs and .exp files with
the lib.exe command.
3. MSVC has many more lint style warnings than
GCC. I turned off signed/unsigned mismatch, dangerous 64 bit pointer
warnings, type conversion warnings, unused var warnings, etc.
4. MSVC doesn't have standard low level io calls
like open(), close(), etc. Add an <msvcio.h> file that creates
macros to rename msvc io calls to normal unix calls.
5. MSVC doesn't allow an empty "default:" block in
a case statement. I added a break; statement to each empty default
block.
6. MSVC doesn't have sys/time.h or
unistd.h.
7. MSVC doesn't like the constant NAN and INF
declarations (1.0/0.0 and 0.0/1.0) in the floating point routines. I
remarked these out for now.
8. MSVC doesn't compile GCC asm inlines.
#ifdef in __asm {} MSVC inlines in message.c to do the things.
9. MSVC doesn't like the floating point comparison
functions in hacks.h for Mint. Replaced these with __forceinline
functions. Also MSVC's version of isnan() is _isnan().
10. References to some of the GNU winapi header
files were incompatible with actual windows headers. #ifdef'ed them to use
straight <windows.h>
11. MSVC's windows.h file doesn't define
SignalAndWaitForEvent() without the _WINNT_VER macro being defined. Added
that to the project.
12. The current build depends on having monoburg,
nant, and the other tools from the cygwin gcc build having already generated
their various files. Since linux gcc is the primary dev platform and will
remain the primary dev platform, simply grabbing a snapshot of these generated
files whenever a new MSVC build is needed is okay I'm thinking. MSVC's
projects are more for MSVC lib or exe builds, and development of integrated MSVC
mono apps, not for work on the core bits of mono itself.
I will have a more complete list when I can grab
the diffs off my computer and send them.
ISSUES:
Can we come up with a solid way of handling
multiple compiler versions. Perhaps the following:
Macros: __GCC__, __MSVC__, __CODEWARRIOR__,
__PRODG__, etc.
Dirs: mono/msvc - MSVC specific projects libs,
includes, bin, etc.
mono/codewarrior - Codewarrior specific projects libs, includes,
etc.
etc.
Possibly a "compiler.h" file..?
Currently I am using _MSC_VER, placing some extra
bits in the msvc version of the config.h file, and #ifdef _MSC_VER including
msvc specific include files where they are needed.
Any comments?
Now to answer the question WHY...
We have an application that needs to be both cross
platform, but who's primary dev environment and tools are based
in Windows. This means that we need the same version of .NET running
on all platforms (i.e. mono, because it's cross platform), but we do primary
tools development in Windows, for Windows, in Visual Studio with MFC,
etc. Obviously this requires both that we have a working VS library
for the mono jit and interpreter for the primary app, as well as CodeWarrior,
ProDG, and GNU compatible versions of mono for the other platforms (i.e.
GameCube, PS2, XBox).
We still need a C# to C/C++ compiler for final
highly optimized release builds of all static assemblies, but that will have to
come a bit later I think.
|
