Boost.Build (Part 1)

Linux developers know "make". The good old fashioned Makefile with targets and dependencies. Makefile's feel warm and fuzzy. They are like an open invitation saying, "Hey, you can come on in. You can type make and everything magically works, it's safe!" Makefiles are the standard- and most platforms know it. There are even tools that can be used to generate Makefiles (cmake, premake4, and qmake).

Boost's Build System is a replacement for make rather than a Makefile generator. Benefits to using Boost.Build:

• Has no dependency on Boost itself. [1]
• Cross-platform support. [1]

The downside is obvious in that no one really uses this tool. This small tutorial explores whether or not this is a useful tool. Keep in mind I'm heavily biased. 

The first thing we want to do is build a Hello World example [2]. I created the following two files in a single folder:

File: hello.cpp

#include <iostream>

int main(int, char**)

{

     std::cout << "Hello World!" << std::endl;

}

File: Jamroot

exe hello : hello.cpp ;

One of the cool things that I didn't know about Boost.Build is that it can build both debug and release configurations using the same command! Simply invoke:

b2 release debug

It creates the following subtree under bin:

bin

  gcc-4.7

    debug

      hello (bin)

      hello.o

    release

      hello (bin)

      hello.o

I think this is actually pretty cool. Very useful if the output of what is being written is a library that will be distributed to users. There has to be more to this, let's continue the tutorial. One of the next parts of the tutorial covers features/properties. The example they give is to turn on some of the builtin features using b2:

b2 release inlining=off debug-symbols=on

Boost.Build is very explicit about what it builds. When this command is invoked, the subtree under bin looks like:

bin

  gcc-4.7

    release

      debug-symbols-on

        inlining-off

          hello (bin)

          hello.o

I have mixed feelings about this; on one hand it's very handy to know how these targets are built. The information is useful at link-time in a lot of cases. On the other hand I think that categorizing these binaries in such a fine-grained way is a little overkill. In conclusion, it's useful but overkill. 

It's also interesting to note that the examples (seem to) encourage multiple executables within the same Jamroot file [3]. I think this is a novel idea because projects are no longer single executables; they can be comprised of server apps, client apps, shared libraries, etc. 

References

[1] http://www.boost.org/boost-build2/

[2] http://www.boost.org/boost-build2/doc/html/bbv2/tutorial.html

[3] http://www.boost.org/boost-build2/doc/html/bbv2/tutorial/properties.html