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

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.

<embed style="width:400px; height:326px;" id="VideoPlayback" type="application/x-shockwave-flash" src="http://video.google.com/googleplayer.swf?docId=7525466052747539502&hl=en" flashvars=""> </embed>

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.

Syndicated 2007-07-02 12:03:30 from Slow and Steady

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

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.

Syndicated 2007-07-01 18:03:30 from Slow and Steady

It’s a girl !!!

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

Syndicated 2006-12-07 09:39:23 from Slow and Steady

More thoughts about MCS and GMCS

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

Syndicated 2006-02-16 03:53:00 from Slow and Steady

automake, make dist and long filenames

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

Syndicated 2006-01-18 14:22:00 from Slow and Steady