Not sure nobody will be interested in 1.1. We are! :-)
Daniel Morgan escribió: > I think building Mono with Visual Studio is good for several reasons - > debugger is awesome, mono.exe should run faster built with visual c++ instead > of gcc, and easier to edit files. > > As for coding guidelines using visual studio text editor, it is not easy > because it autoformats C#. Even when you tweak the settings to be like > mono's coding guidelines, they still are not correct. So, you end up having > to manually go back and fixup the problems. > > As for the 1.1 profile, those building mono using visual studio will not > interested in the 1.1 profile anyways - they want to see the "cool" new stuff. > > > > --- On Tue, 12/9/08, Jonathan Chambers <[EMAIL PROTECTED]> wrote: > > >> From: Jonathan Chambers <[EMAIL PROTECTED]> >> Subject: Re: [Mono-dev] Ideas for Mono on Windows >> To: "Miguel de Icaza" <[EMAIL PROTECTED]> >> Cc: "Atsushi Eno" <[EMAIL PROTECTED]>, "mono-devel" >> <mono-devel-list@lists.ximian.com> >> Date: Tuesday, December 9, 2008, 2:41 PM >> 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]> 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 >>> >>> >> 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 >> > > > > _______________________________________________ > Mono-devel-list mailing list > 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
