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