Sometimes automake is no good… Mono projects

You know I’m an autotools-lover, and that I think that they can easily be used for almost all projects. Well sometimes they are not, one of this cases is Mono projects. Indeed, you may remember that I’m working more closely with Mono lately for my job, and that has made me notice that there really aren’t many great ways to build Mono projects.

Most of the libraries out there are written with Visual Studio in mind, and that’s not excessively bad if they provide solution files for Visual Studio 2008, since MonoDevelop’s mdtool can deal with them just fine (unfortunately it doesn’t deal with VS2k5 solutions which is what stopped me from adding FlickrNet in source form to Portage, limiting myself to the binary version).

There are a few custom Makefiles out there and some mostly wok, but there are also projects like f-spot that provide an autotools-based build system… but with a lot of custom code in it that, in my view, makes the whole thing difficult to manage: indeed it gets out a mix of automake and manual make rules that don’t really rock my boat properly.

It’s not that I just don’t like the way the Makefiles are written, but factoring in the fact that automake does not support C#/Mono natively, you get to the point where:

• the support for dependencies is just not there;
• automake is designed to support language where a source file is translated into an object file, and then linked; C# does not work in that way since all the source files are given when building a single assembly;
• the support for various flags variables is just pointless with the way the compiler work.

I guess there are mostly two reasons why autotools are still used by C#/Mono based projects, the first is that it integrates well when you also have some native extensions, like F-Spot has, and the latter is that it provides at least some level of boilerplate code.

I guess one interesting project would be to replace Makefile.am with some kind of Makefile.mb (Mono-Build or something along those lines for a name) so that they could generate some different Makefile.in files, without all the pointless code coming from automake and not used by C#/Mono builds, but still interface-compatible with it so that commands like make, make clean and make dist work as intended.