I just read a post on meTUX, a German site sponsoring articles on IT issues. I was referred to the site by an email message on the autoconf mailing list. I have nothing personal against the author of this message, nor do I disagree with him on all points, but his main point I do take issue with. He states that autotools, and autoconf specifically, is a collection of hacks. Let me tell you what I think about this by asking a question of my own: If autotools are so bad, why is there no competing product?

Autotools as a packages does two things for the open source developer. First, it provides a convenient mechanism for encapsulating all of the garbage you don’t want to have to do manually, such as creating distribution packages (commonly called tarballs), ensuring your packages contain appropriate open source copyright, installation, and changelog information, and that your packages build using the same procedure on all platforms (except one we won’t mention here). The default installation paths for your packages’ components are chosen based on the GNU coding standards document, as well as the two dozen standard targets supported by Automake.

The second thing that autotools does for you is provide a very portable mechanism for running your configure/make scenario on any POSIX compliant system you can think of. Often we consider only Unix systems such as FreeBSD, Solaris, or Linux. But autotools has been ported to many embedded POSIX compliant platforms, as well. This embedded world is foreign to many of us who just want to get an open source package up and running on our Linux boxes, but the people who work every day in this world are greatful for any tools that just work on their little-known platforms. The people who wrote Autotools understood this issue and tried to design it in such a way that it relies on as little existing infrastructure as possible, basically the M4 macro processor, and a bourn compatible shell. With these design constraints in mind, autotools has a pretty good chance (85%) of just working on a POSIX-compliant platform for which it was never tested or targeted – that (quite contrary to the above author’s comments) is actually an amazing engineering feat, when you consider it.

A common gripe with autotools is that it doesn’t work well with Windows. Not really much to complain about in reality however, as most folks like their IDE’s and such on this platform. I find it simple enough to maintain an MS VC project along side my autotools scripts, and most Windows folks are delighted to be able to double-click on the .sln file and press F7 to build.
My personal gripe with autotools is the stunning lack of good documentation for the high-level concepts of this set of tools. There’s plenty of doc that describes the internals of the product, but the only resource I’ve ever been able to find that does a good job of describing the rational behind autotools is a book commonly referred to as “The Goat Book” because it has one of O’Reilly’s famous animal covers. But, Hey! What am I complaining about? The autotools are open source projects. If I don’t like the existing doc, why don’t I just write some good doc myself?


OASIS Common Base Events

Someone pointed out the OASIS CBE document to me the other day, so I took a few minutes to read about it, and found it very enlightening. It’s very difficult to design a set of data that fits everyone’s needs, yet CBE does an admirable job of it.

In my 10 years experience with event system design (eDirectory internal event system design/maintenance), I’ve found it most useful to provide a variant-record system, where the event type (generally a number or a schema-based string) defines the format of the event data. However, this wide-open way of doing things leaves something to be desired for those wanting to automate the process of dredging for specific bits of data, while not knowing in advance all of the record types that might be processed. Generally, this problem is solved by building the event processing system such that it ignores all events of which it has no fore-knowledge.

Still, even in the eDirectory event system, there were several data fields that eventually came to be recognized as “common data”, or data common to all events, regardless of their meaning, origin, or purpose. CBE attempts to define these data fields on a much broader scale, and I’d say they’ve succeeded. More on this topic later…

Hello world!

Why change the title. It fits – this is my first post to this blog.

As I type this, I’m sitting in a conference room in the Novell Executive Briefing center with folks from IBM and Parity at the first Higgins Identity Summit. This is the last day of this 3-day event and it has been a most excellent meeting. Watch the Higgins and Bandit websites over the next few days to see the effects of our conversations.

I noticed that Higgins is in the news now – check out the vunet article.