Regarding Autotools, and attempts to replace it

In the world of software development on Linux, especially in the open source world, there is a set of packages called "autotools", which abstracts and manages portability between compilers and other aspects of the software build environment. Nobody likes it. In fact, most people who use it hate it. There are many attempts to replace it.

And the problems with autotools are getting worse, because it itself was never designed to have cleanly portable control files between versions. Back when most everyone just FTPed down a tarball, and then ran the prebuilt ./configure, it worked pretty well. Now that people pull a projects raw repo over SVN, BZR, or GIT, and then have to run liptoolize, aclocal, automake, autoconf, etc themselves, and who knows what version of autotools is locally installed, all hell breaks loose.

With respect to all the autotools replacements, such as cmake, Ant, etc, and all the other ones mentioned in Eric Raymond's recent blog post: they ALL are some multiple combination of horribly slow, enforce their own special "one true way" of laying out source trees, are specific to what languages they will deign to handle, have abysmally bad error messages when there is a problem (and being worse than autotools in this respect is an amazing achievement), require the installation of a JVM and a huge pile of buggy poorly documented class files, require the installation of a huge pile of buggy poorly documented Python modules, require the installation of a huge pile of buggy poorly documented Perl modules, cannot intelligently detect and handle optional build dependencies, cannot cross compile, cannot build out of a read-only source tree, cannot build out of tree, and/or cannot build shared object files.

I wish to gods and monsters that this was not true, but it is. And until the writers of the competing build chain systems understand why all this stuff is important, and are willing to support it, autotools will stick around, and people will continue to use it.

This is not to say that it cannot be used better. One of Monty Taylor's herculian tasks the Drizzle project has been pandora build, which is a refactoring and rewrite to the years of cargo-cult accumulated cruft that has infested most autotools based open source projects.

SQL identifier case, Unicode case, and boost::to_upper, all in a fight that nobody will win

The SQL standard says that table and row names are case insensitive. Drizzle table names are in Unicode with UTF8 encoding. boost::to_upper et al mangles UTF8 case. Down this path there is going to be a lot of pain. My own inclination is to tell the SQL Standard to realize that its 2011, no longer 1961, and break all the apps that are lazy about identifier case, but other people will probably disagree.

Multi Master Replication is back in Drizzle

This last March, David Shrewsbury put together a basic implementation of multi-master replication into DrizzleDB link. We were able to actually merge it with the mainline trunk, but then had to remove it until we had refactored and fixed more things. Today, we were able to put it back in.

It's worth reading Shrew's original blog posts, and then trying it out.

Thoughts on node.js and libdrizzle

Today I was chatting with a technical friend, and she mentioned that she has a "todo" of writing a decent node.js driver for MySQL. A bit more chatting back and forth, and http://nodejsdb.org/db-drizzle/ was discovered. It was written to use libdrizzle and drizzled, but since libdrizzle can talk to MySQL, it should work for her needs as well.

I would love to see some work done on how well libmysql+mysqld, libdrizzle+mysqld, and libdrizzle+drizzled handle highly concurrent asynchronous event-oriented workloads such as those generated by all these new node.js applications.

I suspect that all sorts of surprising bugs will be discovered.

Please help us discover those bugs.