[Mono-dev] Ideas for Mono on Windows
pablosantosluac at terra.es
pablosantosluac at terra.es
Thu Dec 11 05:50:16 EST 2008
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
>> 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:
>>>> 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.
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list