[Mono-dev] Ideas for Mono on Windows

[pablosantosluac at terra.es]

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 <joncham at gmail.com> wrote:
>
>   
>> From: Jonathan Chambers <joncham at gmail.com>
>> Subject: Re: [Mono-dev] Ideas for Mono on Windows
>> To: "Miguel de Icaza" <miguel at novell.com>
>> Cc: "Atsushi Eno" <atsushi at ximian.com>, "mono-devel" <mono-devel-list at 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
>> <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
>>     
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>     
>
>
>       
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>