Paco's Blog

Building Mono in Windows for 2006

Background

On the one year anniversary of the article that Kevin and I put together about building mono in Win32, we are still missing important pieces that keep us from realizing our original goal. The goal was to document this tricky process well enough so that more than a handful of folks could build and or patch their mono runtimes and programming kits with relative ease. A mayor contention point remains the core environment that up until now, remains being Cygwin.

Cygwin is a *NIX emulation layer and environment that provides all of the GNU pieces needed to build and even run a great number of traditional as well as new Linux applications in Windows. Depending on how you decide to configure it, you could get a great selection of programs that rage from utilities like tar and grep to servers like PostgreSQL and Apache as well as everything else in between! As with many other great Open Source projects Cygwin has progressed to even include X windows and almost all of the Gnome desktop (KDE is also available). A lot of these applications and other facilities are designed and are dependent of the cygwin1.dll (the main function repository for the *NIX emulation layer it provides).

Mono as well as the Microsoft .NET Framwork are examples of very far reaching systems that are made up by a multitude of components and subsystems. Unlike a stand alone software notepad or calculator which may only have a dozen or so source code files, mono has over 13,000 of them. Building such a system requires a great degree of sophistication and experienced developers that devote a lot of their hours to the build system itself. In the world of Open Source software, the GNU project has had a collection of subsystems that facilitate the compilation, testing and packaging of software projects sometimes referred to as the auto*. These include Automake, Autoconf, Libtool and a few others. The mono project's build system was designed to take full advantage of the GNU auto* tools. In operating systems like Linux and FreeBSD these tools are a mainstay and are usually included even with the most minimalistic package selection that hints of a software development intention by the configuring user.

This is were a system like Cygwin comes in when one tries to write a single build system that will work for all operating system platforms that mono targets. In Microsoft Windows (2000, XP, 2003, etc) one can use Cygwin to build mono. It is important to note that we only use Cygwin for the auto* tools and that we are able to create a "Cygwin Free" product thanks to a gcc compiler flag (CC=gcc -mno-cygwin) that forces independence from the cygwin1.dll.

The -mno-cygwin flag alerts the linking process to use MinGW libraries. MinGW and MSYS are themselves a fork of the original Cygwin project that have the same objective of bringing GNU and POSIX functionality to Windows but effectively cut down on the complexities, dependencies and weight that Cygwin could impose.

In fact, many of the ported components that are at the root of GTK+, mono and applications like the Gimp for Win32 were built using MinGW so that they would not depend on cygwin1.dll.

The Problem

You see, when O'Reilly published our article, I tried to "bottle" a vintage of Cygwin in a CD that would be optimized for would be mono builders in Windows, but it came at an enormous 400+ MB. It took me about three weeks to understand and learn how to transform the proprietary on-line installer and software distribution system that Cygwin uses, in order to make it run from a CD by clicking on a menu option on an autorun application I created.

Today you could get the latest and greatest Cygwin but you would have to be so careful to not pick and install components like their glib or GTK parts since it would be incompatible with the ones that we use for mono and Gtk#. There are articles out on the mono wiki that are very well written and will even tell you what to do and what to stay clear off, but I believe there has to be a better "one installer does it all" way of doing this.

The Proposed Solution

For the past couple of weeks I have been putting together an installer that brings MSYS, MinGW and some additional tools and configuration settings with the mono developer in mind. A design objective has been to try to keep it down to one downloadable file that weights in under 30 MB. It should be parallel installable with existing copies of Cygwin or Microsoft Windows Services for Unix. It should use an Inno Setup installer that will use similar conventions as the Mono Combined Installer for Windows and the Gtk# Installer for .NET Framework. Should there be any environment variables that are determined needed by the mono build system, these would be already included in the /etc/profile so that all users inherit them on first use. Finally, instead of lumping all subsystems and components into an opaque blob, there would be a detailed granular selection that clearly states that component's name its size and the version packaged.

I already have a first prototype that is quite complete in content but did not effectively build a mono tarball on my first try. You can find the installer here.

At this point I ask for anyone that has made it this far into reading this long blog post to leave me feedback and tell me what he/she thinks about this endeavor. Ideally, the mono community could polish a build environment that we can call our own and that can be consistently depended on and shaped to our liking and needs.

Posted by martinf at January 9, 2006 06:00 PM