[Mono-dev] Ideas for Mono on Windows

[Miguel de Icaza]

Hello,

    I think it would help to keep in mind what the objective is for the
second approach: to make Mono easier to hack on for Windows developers
and to encourage contributions. 

    We agreed on the second approach (Hit F5 in Visual Studio, get a
fully built Mono):

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

I am wondering if there is a lot of value in building the 1.0 and 2.0
profiles of Mono with Visual Studio.

The 1.0 profile so far has limited uses: bootstrapping and embedded
scenarios, they are both valuable, but they probably should not be
mandatory for the "F5 experience" which is to say: how do we enable more
developers on Windows to easily hack on Mono.

The multi-stage build process from Mono (where we build mscorlib a
number of times) might not be necessary to achieve this goal, I would
postpone this for now and not bother too much with this.

I saw the discussion about some of our libraries that we still compile
against the 1.0 profile.   I think that we can do two things here:

	* We could build policy files that remap 2.0 to the 1.0 
	  assemblies on Linux so that executables built on Windows
	  using these 2.0-based applications continue to work.

	* Alternatively, have a new stage that "redirects" the code
	  to a 1.0 profile API to ensure full compatibility (this
	  is what JB suggested online).

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

In order of priority I think we want:

	* Ease of use for developers to get started with Mono hacking.

	* Ease for users to get a version of Mono, and build a version
	  from SVN that they can use.

	* Eventually be able to produce a fully compatible Mono from 
	  Visual Studio with a single command.

I believe that we can achieve the last point with some custom tools in
the future, using a last stage pass that uses our runtime and a
"monolite" component.   I say a "last stage" merely because I think that
we should postpone a full build of Mono that includes the 1.0 profile
from Visual Studio if this is too difficult.

> 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?

I do not anticipate to find too many problems with the partial approach
(where the 2.0 is the only platform tested).   There certainly will be
some, but those problems even happen today with people using Linux or
Cygwin.

If it becomes too much of a problem, we can revisit at that point the
setup and augment it.

Miguel.

> 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.
> 
> Thanks,
> Jonathan
> 
> 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
>         
>