Slow and Steady

My Novell Hack Week project: Implement support for Mono in Automake

nospam@example.com (Raja R Harinath) — 2007-07-02T06:33:30Z

This week was hack week for all the Open Source hackers at Novell, where we got to work on ideas and projects that we were personally interested in. I decided to work on something that I've been planning for a long time, ever since I joined the Mono project, in fact: add support for Mono in Automake.

It has been a while since I hacked on the automake source tree, but I didn't have too much trouble getting started. In the end, I got most of the features I intended for it:

support for building Mono exes and dlls

support for installing them in the GAC

support out-of-tree builds

dependency tracking on sources

support for specifying resources, and tracking dependencies on them

support for specifying references, and tracking dependencies on them

support for multiple languages, include C#, VB.NET, Nemerle, Boo

easy extensibility of the support to other languages -- essentially, just need to add the filename extension of the language to SUFFIXES

bundled autoconf macro to detect installed compilers and other tools

... and some examples, test cases, and documentation to explain how to use all of it

Stuff missing include

autoconf macros to detect if libraries are installed or not

support for Microsoft's compilers -- basically a question of replacing '/' with '\' in filenames, where appropriate

support for response files -- mainly wrt distributing sources mentioned in them

real life experience with actual projects using all the above features

The whole effort took up most of the five days. I spent much of Monday checking out the code from CVS into git and looking at how support for C and other languages was implemented. I had most of the basic support done by Tuesday, got all dependency tracking working by Wednesday, and added documentation, autoconf support, and GAC-installation support by Friday afternoon. I'm very happy that I spent the time upfront to import the project into git, since it saved me from spending a lot of timeslices tracking my changes.

The code is available as a series of patches to Automake (packed conveniently in a tarball), and there's also an example project that shows how to use it. I also have a "lightning talk" short video about the project.

As much as I enjoyed the coding, I also thoroughly enjoyed working with the whole Bangalore open source team, all in the same conference room for five days, with everyone having a good time, and good food.

It's a girl !!!

nospam@example.com (Raja R Harinath) — 2006-12-07T22:09:23Z

I became a dad this morning (6:25am).

More thoughts about MCS and GMCS

nospam@example.com (Raja R Harinath) — 2006-02-16T15:53:00Z

Martin got GMCS to work on Windows, with a small caveat -- there's no API to change the MethodAttributes of a MethodBuilder. I have a couple of observations:

the caveat isn't really a big deal. You only need to set NewSlot when there is a new keyword used in the declaration. Otherwise, it's useful but not necessary (See bug 74852 for the gory details)

these changes, coupled with my older changes should allow us to have more code similarity between MCS and GMCS. Specifically, I think we can put in a couple of stubs: DropGenericTypeArguments and DropGenericMethodArguments into MCS and eliminate a big part of the textual differences between MCS and GMCS in non-generics related code. We already started on this in doc.cs

automake, make dist and long filenames

nospam@example.com (Raja R Harinath) — 2006-01-19T02:22:00Z

Harish noticed some strange behaviour with 'make dist'. He later found out that it had to do with a file with an overly long pathname. Automake 1.9 by default forces 'tar' to work in the "most compatible" mode, and that mode supports pathnames only upto 99 characters long.

The solution is to ask automake to request tar to use the POSIX standard 'pax' format. Add a line like the following in the top-level Makefile.am.

AUTOMAKE_OPTIONS = tar-pax

However, life wouldn't be interesting if it was so simple.

This option is not backwards compatible: older versions of automake don't know about it, and they barf on unknown options

The tar that comes with SuSE 9.2 (IIRC) doesn't support 'pax', but does support the 'ustar' format, an older POSIX standard. Luckily automake has an option to request 'ustar' format: tar-ustar

That gets us to mono's solution. Here's the configure.in tidbit that does the trick:

# Gross hack to enable 'make dist' on automake 1.9+tar 1.14.

# The extra brackets are to foil regex-based scans.

m4_ifdef([_A][M_PROG_TAR],[_A][M_SET_OPTION([tar-ustar])])

Now, please forget this trick, it's gross. Just use automake 1.9.

PS: There's an even simpler trick: start distributing ZIP files (make dist-zip) instead

MCS: Implemented ::-lookup (qualified alias member) feature

nospam@example.com (Raja R Harinath) — 2005-08-03T08:26:00Z

Today, I added my first "tick-mark" feature to Mono's C# compiler: qualified-alias-member or '::' lookup. It's a relatively small feature, and doesn't impact much, code-wise.

In all, it took about a day's worth of effort from start to check-in. But, that one-day effort needed quite some preparatory work. I'd pretty much decided on the approach a couple of months ago, and had a reasonable plan-of-attack, and was looking for an opportune time to work on it. More importantly, the past few months I spent incessantly refactoring the name- and type-lookup facilities in the compiler has paid off, making the task of implementing '::' trivial.

Thread-safety and me

nospam@example.com (Raja R Harinath) — 2005-06-25T02:14:00Z

I'm thinking of working on fixing Mono's Dictionary to be thread-safe.

It seems ironic: I wrote a large part of that Wiki page, and I'm in large part responsible for the dictionary code not being thread-safe. "Blame" me for the use of the move-to-front heurstic in the dictionary code, and I must say, it was a beautiful piece of code: see how simple it made the 'Remove()' code.

Of course I've disliked threads all along, and this gives me more reasons to blame threads for the ugliness they bring into the world.