Day 3: Build Systems and Black Arts

Build Systems

After the prior experience of creating a template project some attention was applied to the build infrastructure. Banshee uses a combination of GNU Make, supported by Autotools, and xbuild. We happily go about development with the knowledge that MonoDevelop will keep them synchronised.

The presence of two systems is a headache for maintainers since there’s two sets of configurations that need to be considered (e.g. in templates) but also to developers using the Unix IDE since editing project files is an awful experience; I say this as a developer because looking at XML makes my stomach knot, even JSON files don’t evoke such a visceral reaction.

You can probably predict my response when my mentor, Andrés, suggested that the Makefile just call xbuild. “But then make depends on xbuild!” I cried; his response that doing so would reduce maintenance made sense, but made me think of how we can better use GNU Make.

To illustrate, although not proficient with Autotools, I have used Make to build software. One immediate difference I see in the makefiles I use compared to those you can find in any basic tutorial is the listing of source files verbatim instead of using make functions. This has an important consequence, changes like adding or removing a source file from a project means that you have no other option than to modify the makefile; used in this way a makefile is no better than its project file counterpart.

I’m also uncertain of how we can check dependencies if we were to move to a completely xbuild managed system, dependency information has the same duplicate representation and, although I love Make, project files are not optional, as most contributions come from people using MonoDevelop, while we could (arguably!) live without makefiles.

For what it’s worth, the basic tutorial I learnt Make with can be found here. It’s actually a really good one, providing a great base for extension and encouraging the reader to investigate further.

Black Arts

As I noted on Day 2 we had some issues accessing DBus properties for objects exported from none CLR languages. This was unforunate but had an easy workaround.

Since then, I took a long, hard look at dbus-sharp. It was an instructive experience to see how they use the Intermediate Language Generator class to create interface implementations on the fly, mapping those calls to the appropriate DBus methods, and figure out how to extend it to map CLR properties to DBus ones.

While the above experience had an inexpressible value of fun and was definitely rewarding, the time from patch submission, through review and the new version reaching users probably means that I’ll be writing those decorators anyway! A perfect job for the early hours when I can safely limit any thinking to muscle memory…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s