[Mono-dev] Upgrade dependencies for VS build

[Michael Jerris]

>From: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Jon
Chambers
>Sent: Friday, September 15, 2006 10:43 AM
>To: Mono Devel List
>Subject: [Mono-dev] Upgrade dependencies for VS build
>
>Currently to build mono in VS, one must download a VSDependencies.zip
that contains required dependencies for building mono. This zip
>contains an older version of glib, as well as other things. On my
machine I've upgraded to the latest version of glib on windows >2.9.5
and done some work to get things building with this. So, how could I get
this back into the VSDependencies.zip (I assume we >would rather be
using this newer version of glib)?
>

The problem is bigger than that, when building with visual studio after
version 6, it uses a different version of the c runtime, and you can not
intermingle different versions of this runtime when passing references
such as file handles between dll's.  Because of this you need to have
glib (or hopefully eglib soon) built with the same compiler version as
you are building mono.  Currently there is very poor modern visual
studio support for glib, although I am sure that would be fairly easy to
rectify.  The other option would be to have different versions of the
binary glib files for each of the different runtimes.  (6, 7.0, 7.1, 8
both release and debug), but this is quite messy.  

>It seems like the only thing the user really needs to download is the
latest glib package. The only other thing I think I need from
>VSDependencies is an empty unistd.h file, and a sys directory with a
time.h and a param.h. The unistd.h is there rather than >#ifdef'ing the
source code. I don't think there is anything special about the included
time.h either (I'm wondering if I could just >include the standard
windows one)? Maybe we could remove the dependency for
VSDependencies.zip altogether. 

Going to a pure VS build will take a few more steps as well, we need to
generate the bison generated files for monoburg.  For this, I have a
patch in the works that generates a temp file parser.c.win that can be
checked into tree, so that people building with msvc don't need to have
bison to build, this file will need to be re-generated if there are any
changes to monoburg.y.  Please note, you can not just have a single
generated parser.c file for windows and unix in tree as the output of
bison is different for windows and unix.  After that, we need to address
building the platform specific files that are generated from monoburg.
This should be fairly easy to generate from different targets in the
project files.  From this point, it should be fairly easy to build at
least libmono completely in tree with only visual studio and without
cygwin.  The tests are a different story, and would have to be handled
later.

The biggest issue in all of this is the glib dependency.  How do we
address this, do we just use different binary versions, do we focus our
efforts on getting a clean build of eglib and completing that for
windows.  I think for the short term, I would be happy to provide glib
binaries, at least for visual studio 8, for people to use.  The rest of
the files not related to glib in VSDependencies (such as the other
header files) should probably just be checked into tree in a separate
directory that can be included from the project file.

>
>Also, I'd like to setup the release target correctly.

I would agree with that as well.

Also, see attached, my first draft of the patches to the monoburg build
for VS provide for input on the approach used here.

Thanks
Mike


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: monoburgVSbuild.txt
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060915/90267cb1/attachment.txt