Sunday, April 21, 2013

Building Boost From Source

This topic is all about building projects using the Boost tools (aka bjam). Whenever I deal with bjam there is an automatic cringe. The first case that I'll go over is building Boost. Keep in mind that this is being done in Ubuntu:

Step 1: Go to http://www.boost.org and download the latest tarball of the sources.
As of this writing, the current version is 1.53.0. The tarball has an extension of .tar.gz. 

Step 2: Unzip and Untar the file:
This is just basic linuxy knowledge. If you want more info about gunzip or tar check the manpage.

gunzip boost_1_53_0.tar.gz
tar -xf boost_1_53_0.tar

Step 3: Run bootstrap.sh.
If the reader has skipped ahead of the boost instructions or has prior knowledge of the Boost.Build process they know that ultimately we run a program called b2 to build Boost. The b2 application is Boost.Build (get it, b2?). We are also missing the bjam application; bootstrap.sh also generates this program. 

./bootstrap.sh

After running the bootstrap script there will be two new executables in the same directory: b2 and bjam. Also take note of the output from bootstrap.sh; it shares what components will be built along with what components will not build. This can be important later! If missing components look into installing the source components from Ubuntu's main repository. 

There may also be situations where bootstrap.sh doesn't find the development libraries. For example, say the machine has installed python in an obscure location. The user can invoke bootstrap.sh with --with-python=yourobscurelocation. There are a lot more build options that can be configured. The best tip I can give you is to open bootstrap.sh in the best editor you have (vim) and take a look.

Step 4: Run b2.

./b2

At this point boost should build. The application spews out what libraries are about to build before starting. This is annoying as this is important information! For example, if dependencies on the source code for posix threads cannot be found on Linux the thread library will not report as "building". The output looks like this:

Component configuration:

    - atomic                : building

    - chrono                : building
    - context               : building
    - date_time             : building
    - exception             : building
    - filesystem            : building
    - graph                 : building
    - graph_parallel        : building
    - iostreams             : building
    - locale                : building
...

This output can save you a lot of time. Make no mistake about it: building boost takes a LOT of time. If this output is ignored (as it scrolls by really fast) the user may end up with only part of the boost libraries having been built! Seems like there should be a pause here for input.

Results

The results should be that the boost libraries are placed inside of directory tree rooted at bin.v2. Each directory is under:

bin.v2
  libs
    library-name
      compiler
        debug/release
          link-mode
            threading-multi

Both static and dynamic libraries are available. Another way to get at the libraries quickly is the stage directory which contains symbolic links to all libraries under bin.v2. Another directory of interest is the boost directory, that contains all of the headers used when developing against boost.

No comments:

Post a Comment