[Mono-dev] Upgrade dependencies for VS build

[Jon Chambers]

As far as the version, the current glib depends on c runtime version
7.0.2600.2180. The newest glib depends on the same one. As the previous
version is working (somehow in VS 2005), I'd assume the newest version would
continue working?

- Jonathan

On 9/15/06, Michael Jerris <mike at jerris.com> wrote:
>
>
> >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 HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060915/b88d8179/attachment.html