[Mono-dev] Ideas for Mono on Windows

Jonathan Chambers joncham at gmail.com
Tue Dec 9 14:41:16 EST 2008


      I broke down the 'Mono on Windows' topic into two distinct approaches.
I have mainly been working on the second approach as it seemed to be easier
and provide more value.

The first approach is to provide a way to build mono on windows without
cygwin installed. This approach provides uses no MS tools and provides no VS
integration for the class libraries. The runtime would still be built with
MSVC at this point in the plan. It's simply a way for Windows developers to
quickly build mono on windows. It should be much faster than the current
cygwin based build and require let setup.

The second approach (the one I have been working on) was to provide a
'prepare' tool to generate csproj files for all the class libs. I also
generate a solution containing all the projects. The user can then build all
the mono class libraries (and unit tests) with one click (it's also per
profile 1.1, 2.0, 3.5).

So as for an update to the second approach. I have a rudimentary Makefile
parser and am using it to generate csproj files for the class libraries. I
have run into a few problems/issues:

1. The conscensus on #monodev was that the build could use the MS compiler,
but that we should reference mono class libraries as references. So, I build
corlib first and then try and build the System.dll referencing our corlib
rather than the MS one via -nostdlib compiler option (for the 1.1 profile).
Visual Studio 2008 allows users to specify what framework version to target
for a specific project, but 2.0 is the minimum version (2.0, 3.0, and 3.5
are the options). The csc compiler errors out when building System.dll as it
is looking for 2.0 specific items in corlib. The specific error is:

error CS0656: Missing compiler required member

I hacked around this by making that field public when build inside of Visual
Studio. However, that is a hack and some in #monodev seemed to indicate we'd
hit more issues going down this path.

So, in short I think we may be stuck trying to build 1.1 profile libraries
(referencing our 1.1 corlib) using the csc compiler.

I have a couple questions that hopefully I can get some responses on.

1. What's the impact of building the 1.1 class libraries against the 2.0

2. Should this approach (VS integration) be able to build a fully working
mono image?

3. If so, are we confident enough that contributors could use this build
mechanism to make changes/patches? Or would this be viewed as a second
class, and we would expect them to build on Linux or with cygwin before
actually commiting changes?

4. If we don't expect this approach to build a fully working mono image,
what exactly is the goal/use case? Is it just so Windows hackers can quickly
build a single class library in VS? They can debug a class library in VS?

I'm still hoping to make things better on Windows for mono, but am not sure
which direction to go now. Any (potential) mono hackers on Windows please
let your opinions be known.


On Fri, Nov 14, 2008 at 4:42 PM, Miguel de Icaza <miguel at novell.com> wrote:

> Hello,
> > The upside of the mechanism I am using is that all of that would still
> > work the same, because I am still using the .sources files instead of
> > having a .csproj.  The downside is we still wouldn't have .csproj's, so
> > it doesn't make working in VS any easier, it just makes it possible to
> > build Mono for Windows in under two hours.
> Thanks for this information.
> Is there a reason why we could not generate the .csproj files from
> the .sources and the Makefile settings for the entire tree in one
> "prepare" step?
> We need to have a good Visual Studio experience from the get-go and not
> only a faster command line buidl.
> Miguel
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20081209/90e4f36b/attachment.html 

More information about the Mono-devel-list mailing list