Hey Jonathan, My interest is mainly the first approach, but building class libraries is an important part of either approach, so thank you for your effort on this. :)
I would say especially for your use case, we probably don't need to worry about the 1.1 profile currently. All contributing is probably going to happen in the 2.0+ profile, given how complete and obsolete 1.1 is. The only concern then is libraries that we only ship runtime 1.1 versions of. Mono.Cecil.dll had been mentioned as one of these. We probably need to come up with the list of assemblies that this includes. Most, if not all, would probably be fine if they were compiled against 2.0 for users' local testing. Obviously, there are other factors in play such as correctness and cross-platformness, but I don't see any reason why users' patches wouldn't be accepted if they were written on Windows. jpobst Jonathan Chambers wrote: > Hello, > > 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 > 'System.Threading.Thread.get_ManagedThreadId' > > 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 > corlib? > > 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. > > Thanks, > Jonathan > > On Fri, Nov 14, 2008 at 4:42 PM, Miguel de Icaza <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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@lists.ximian.com > <mailto:Mono-devel-list@lists.ximian.com> > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
