Comparing "bb" and "ekam" by request

Comparing "bb" and "ekam" by request

I recently received a request to compare my C++ build tool with "ekam". I have to admit that I haven't really looked at ekam beyond the superficial clicking around on a few web pages over a year ago, so I'm coming at this "cold". This post is basically a stream-of-consciousness log as I poke around at the documentation, in other words. I can't actually build it and run it (more about that below).

Right off the bat, my build tool (let's call it "bb", since that's how I usually invoke it) is not open source. It could be, but it isn't. I won't get into why -- too much drama about that in recent posts already. ekam is open source.

According to its Quickstart page, Ekam is said to use C++11/C++0x features, which means it relies on the "unreleased" gcc 4.6 (or later). I assume the wiki page is a bit out of date since gcc 4.6.0 landed on March 25, 2011.

"bb" is pretty boring C++ by comparison. I don't even think of version numbers when I write C++, to be honest. I actually hate programming languages where versioning matters - see a prior rant. I guess "bb" is technically C++98, but that's not a conscious decision. The mix of C++ I use is basically C with the STL, classes, and one or two other things I'm probably forgetting. I don't use the whole buffalo, in other words.

In practical terms, this means I can build my own build tool on all of my Linux boxes and my Macs. I imagine I would not be able to build Ekam because I do not have a sufficiently advanced version of gcc installed.

On the topic of platforms, according to the Ekam wiki, it had FreeBSD and Mac OS X support but it has "atrophied". However, if the wiki itself is out of date (like with the gcc release info), Ekam itself may have been rectified to work on those platforms again.

(Then again, I just found Capn Proto docs which suggest it's Linux-only and best used with Eclipse. Those pages seem to be more recent so perhaps the Wiki is correct.)

"bb" only has binaries for Linux x86_64 (known to work on Slackware64 13.37 and 14 and RHEL 5) and Mac OS X (known to work on Mountain Lion), but I've gotten it to compile and run just fine on OpenBSD. I bet I could probably make it run on FreeBSD without any funny stuff, but I haven't actually tried it yet. I guess I need to put another test partition on one of my scratch boxes and give it a spin.

I suspect the reason Ekam is platform-sensitive is that it does neato (and spooky) stuff to figure out what you're doing. It basically uses (again, according to the Wiki) LD_PRELOAD to get into your compiler's "brain", and then intercepts library calls and sniffs around to find out what's going on. This seems to let it "discover" a great many things about what it takes to build your project.

"bb" has no magic or cool stuff. It just parses .cc and .h files to look for three things:

1: #include <system_header.h>
 
2: #include "local_header.h"
 
3: int main(

I guess technically it has a side case for #2 where it will notice that you're including "foo.pb.h" and will interpret that as a protocol buffer. Then it'll go out and look for foo.proto and run 'protoc' to create foo.pb.cc and foo.pb.h in a "genfiles" directory. This is baked into the tool.

Anything outside of those triggers is not going to be picked up. I suspect Ekam will pick up a great many things and thus technically wipes the floor with "bb" in terms of detection, but at the cost of portability. There are some other potential quirks involving platforms which use a statically-compiled compiler. "bb", on the other hand, is a pretty boring Unixy program that will probably compile and run most anywhere.

Ekam also supports protobufs, but it seems to require some extra steps to make it happen. "bb" just wants to see the right sort of #include, a .proto file, and 'protoc' in your path.

Ekam has continuous building and client/server magic. "bb" has neither. This basically means that you can keep editing things and Ekam will notice them and automatically re-build as appropriate. "bb" makes you run it again by hand, just like make and friends.

Ekam talks to Eclipse with a plugin. "bb" has nothing of the sort. I write my code in nano (yes, really) so it doesn't really work that way for me.

Ekam can build itself. "bb" can, too. They both have bootstrapping scripts. Ekam's bootstrapping seems to be relatively clever and smart: it looks like it keeps bashing things together until they "stick":

When Ekam builds itself, some errors will be produced, but the build will be successful overall. Pay attention to the final message printed by the bootstrap script to determine whether there was a real problem.

The reason for the errors: Some files are platform-specific (to Linux, FreeBSD, or OSX). The ones for the platform you aren't using will fail to compile, producing errors. Ekam will figure out which files did compile successfully and use those. For example, KqueueEventManager works on FreeBSD and OSX but not Linux. EpollEventManager works on Linux but not any other platform. But Ekam only needs one EventManager implementation to function, so it will use whichever one compiled successfully.

"bb", on the other hand, has a bootstrap script which spirits a copy of the source code and required libraries from my main tree into an empty directory and then throws the whole mess at g++ to get a binary:

echo_run g++ \
  -Wall -Werror \
  -I.. -I$TMPDIR $PB_CFLAGS $PB_LIBS \
  $SOURCES \
  -o $OUTPUT_DIR/dep_cli

It isn't pretty, but it's not supposed to be. As soon as that much works, it's possible to turn around and run it to build itself in the usual fashion.

Why "dep_cli"? It's dull, but here goes. "dep" is the name of the class which does most of the work at the moment, and "dep_cli" is just a dumb little wrapper with enough of a main() to start it up. See, I said it was dull. Why "dep"? It's a "Dependency" - a part of the project.

"bb" can "stamp" binaries with build details. This is why "dep_cli -V" will spit out a build time. I don't know if Ekam has that as an option.

"bb" has several build types. At present, it does "debug", "coverage", a default called "bin", "opt", "optstatic", and "prof". Those essentially manifest themselves in terms of different gcc compiler and linker flags. They're hard coded at the moment but I intend to expose those via a config file for overriding and augmenting the stock list. The build type also determines where the "genfiles" (stuff like protoc output) and output files (objects, binaries) wind up. This is important, since you don't want to mix up your objects from different "flavors" of builds.

I can't tell if Ekam has build variants. I suspect it does, knowing the sort of build environment its author came from, but I can't find hard evidence either way from the docs or a cursory romp through the source browser.

Ekam seems to support parallel operations with a "-j" flag just like Make. "bb" does not. It is decidedly serial. It probably has enough state information to safely run things in parallel and block others until the constituent parts have been (re)built, but at present it does not. It hasn't bothered me enough to make me try to write it yet -- my builds are fast enough for my purposes right now.

The "bb" source does not contain the word "factory" either in the actual project code or in any of the helper classes found elsewhere in my tree. (Sorry.)

Ekam has a warning about being experimental and not being ready for real use. I doubt it's actually that bad, but that's what it says. "bb" has no such warning, but you're still at the whims of a binary-only build tool which you haven't funded and may cease to exist at any time (just like any other project).

I actually use "bb" for "production" stuff, or as close as I can get to it. For instance, it builds all of the stuff behind my Super Trunking Scanner site: the stuff which uses GNU Radio to chug down raw I/Q data from my USRP, the MP3 generation and metadata logging to MySQL, the RPC client to push calls to production from my logging machine, the RPC server to accept those calls, and the CGI stuff on my web server to hand out those MP3s and JSON lists of calls. It's all C++ and it's all built by this tool.

Other stuff? fred. "publog", the software which generates these very posts, Atom feed, protofeed, and books. The backend for the web store which sells my books, and does the "Virtual Rachel" logins, sales, and product management (so you can't request a book you haven't paid for - naughty, naughty).

... and, well, everything else I do in C++ nowadays. I write stuff for my clients using it and then write them a nice Makefile when it's ready for handoff. They're welcome to use "bb", too, but I give them the power of not being bound to a proprietary build tool as a matter of honor.

Final thoughts? Ekam makes me say "wow" - capturing library calls to stay on top of things is way beyond what ordinary build tools do.

"bb" makes me say "eh, it works" - to me, it's boring.

But hey, I'm obviously biased. The question is: what do other people think?