[Mono-dev] Ideas for Mono on Windows
monodanmorg at yahoo.com
Tue Nov 11 18:03:26 EST 2008
I year ya!
I stopped hacking on mono on windows. I only run released versions of mono on windows via Novell's windows installer. As for hacking on mono, I've been using the mono / open suse vm ever since.
At first, you could create a branch in svn which would be a place to start so others could participate in hammering mono on windows into shape. Then when it stabilizes, merge into svn trunk.
A Windows Installer designed to install Cygwin, gtk+ and dependencies, and whatever else necessary to build mono on windows out-of-the-box. I believe Paco may have tried to create something like this, but it was the size of a CD to download.
If you look at other free software projects, they use gcc on Linux but they use Visual C++ on Windows, ie. OpenOffice.org and Mozilla. So, it makes sense that we do the same.
Anyways, I like your idea Jonathan. I believe Miguel and others are open to the idea too. It just requires someone to get it started.
--- On Tue, 11/11/08, Jonathan Chambers <joncham at gmail.com> wrote:
> From: Jonathan Chambers <joncham at gmail.com>
> Subject: [Mono-dev] Ideas for Mono on Windows
> To: "mono-devel" <mono-devel-list at lists.ximian.com>
> Date: Tuesday, November 11, 2008, 5:10 PM
> Hello All,
> Mono on Windows has never been easy. However, lately
> things to have
> continually gotten worse (or I and others have just gotten
> more annoyed).
> Setting up an environment takes a lot of effort for a
> normal windows
> developer. Cygwin and the whole Makefile based process is
> very foreign for
> Windows developers. Not to mention the busted make in
> cygwin and cygwin
> issues on Vista (amd64). Most people have had enough
> interest in building
> mono on windows that they took the time to work things out
> (usually at least
> a day). But that's just the first time; try setting
> everything up again on a
> different machine or updating your cygwin and things start
> I see the basic issues as:
> 1) Cygwin development environment is less than ideal.
> It's foreign to most
> Windows developers and is a barrier to entry for most
> 2) Debugging is mostly impossible. gdb seems to provide
> little help on
> Windows (echoed by others on #monodev)
> 3) Compilation takes forever. I am working on a Dual Quad
> Core machine (8
> cores) at 3.6 Ghz. The mono build process still takes hours
> on my machine.
> This may be aggravated by virus scanners or other similar
> software, but the
> fact remains that all Windows users run virus scanners.
> As to not just be a complainer, I am offering some
> suggestions/ideas and
> hoping for others to do the same (or at least critique mine
> ;-)). Before I
> offer any suggestions, I think we need to balance between
> two things. One is
> making life easy for the mono build/package team to produce
> a Windows
> product. It's not real easy now, but we shouldn't
> make it any harder. The
> second thing is making life easy for those who wish to
> work/contribute to
> mono on Windows. This second item is tough at this point.
> 1) We should consider using MSVC as the default compiler
> for C code on
> Windows. I can compile the entire Visual Studio solution
> for the runtime in
> minutes. It takes 20-30 seconds if I do a parallel build.
> We can also use
> the Visual Studio debugger on Windows, which IMO is betten
> than gdb on
> 2) Two propositions for the class libraries have been
> mentioned previously.
> One is a lightweight, 'managed make' system that
> could be run easily on
> windows in place of all the build infrastructure provided
> by cgywin. This
> obviously allows us to keep using Makefiles on other
> platforms and keep a
> unified build process, but requires someone write the tool
> (and maintain
> it). Another option is to moved to MSBuild/xbuild for the
> class libraries.
> This would change the build process on all platforms, and
> require some
> fixing of our current xbuild tool. MSYS/MinGW has also been
> mentioned, but I
> don't consider that much better than Cygwin. I
> attempted to get it working
> one time, but gave up after a few days of hacking.
> Simply opening a csproj file for a class library, hacking
> on it, testing
> under .Net and mono, and then contributing the changes
> seems a like a good
> goal to aim for in regards to contributors. The
> build/packaging guys can
> respond with what they are looking for on Windows.
> Any thoughts/responses on making mono better on Windows is
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list