A good build system is hard to find

I was just reading Jan’s post about how to write a good build system

I’m in the need for a portable, fast build-system.

While I’m not about to write a build system in lua – or anything else, I thought I’d pitch in my thoughts as I’ve been having a similar problem recently. The problem is, autotools is the only system that doesn’t require some prereq to be installed on the system … other than a working build system. The only real downside to autotools (other than needing to learn m4) is that it is useless on Windows.

As Jan says, though, the other systems fall down on the make dist part. This is way important to me, as I also work in my tree alot and I really want to have an automated step to make sure I’m packaging up all the files I need, but not too many. This leads Jan to the inevitable choice of building his own

As a matter of fact here I stand without build-system that meets my needs. My current target is building the MySQL Proxy on Linux, MacOS X and win32.

Throwing lua into the game as a nice side-effect: the scripting language is clean and simple. You can also think about adding the lua-src itself to the build-system to do a full bootstrap in case the user doesn’t have it install

First problem – if the user doesn’t have the build system, and if autotools won’t cut it, then how are they going to build the lua-src.

I’d like to point out that most of this is because Windows is crap. The autotools design goal of not requiring user to install a special build system other than Make is a great one. But because Windows can’t even manage to ship a decent POSIX environment, this is broken. Ever tried sharing source with someone who’s using VisualStudio? Ever get pissed off because there’s no way to have the source figure out where a library dependency is without setting some property in the source by hand?

Anyway – I do think Jan is on to something (as usual) but I don’t think the whole system needs to be rewritten – just autoconf.

Automake runs on the maintainer’s machine, as does autoconf, but the automake output are the Makefile.in files that autoconf replaces stuff in. There’s nothing really broken about this. make, make dist, make distcheck should all still work (ok, except on Windows where they don’t have tar… my sympathy is low) But if you made a program in lua that created something like a configure script that could be run with minimal install requirements on the client (I think needing lua is ok here – as Jan says, it’s easy to install)

That leaves the requirement of producing MSI targets. I think this is a requirement that should be shucked, because it’s not an apples/apples thing. MSI files are the same as RPMs or DEBs. They are packaging, not part of the build, and I think if emitting them is part of the needs, then the build system also needs to be able to make debs. Divorce the work of making MSI files from the build and I think the task is really doable in the short term.

I think that the m4 stuff in autoconf is the only part of autotools that people really get annoyed with. So kill it. Replace it with lua. Or python. Or anything that’s cross platform and low impact. (and by that I do not mean Java – sorry guys, the nightmare that is installing Java environments is a subject of an upcoming rant)

Powered by ScribeFire.

erlang and MySQL Cluster

Ok, in case you just showed up going “finally!”, I’m sorry to let you down – I haven’t yet ported NDB API to erlang.

But I should – and I want to.

Brian was just talking about concurrent program and mentioned erlang. Turns out that when I was starting off working on the NDB/Connectors, Elliot asked me if I’d considered erlang. Always up for learning a new language I did a quick check, but there were no swig bindings, so I put it off until later.

Then later came and I still hadn’t written any code, so I found a book online and started reading. I have to say erlang is very cool.

There is no way on earth I can wrap the NDB API in any meaningful way using erlang. However, I might be able to reimplement the wire protocol in erlang and have the resulting thing be way more stable and scalable. Thing is – it really made me thing we should reimplement all of NDB in erlang. It handles several of the tasks done by the NDB system already by itself – and it’s not C++ so it doesn’t crash and die every three seconds. On the other hand, I don’t think it’s as fast as C++ yet – so our speed-hungry friends might not want to play.

However… hey Brian – wanna sit down an write a new clustered database engine for MySQL using erlang? Could be fun…

Powered by ScribeFire.