Boost libraries are now supported in biicode

As a C++ developer I love the Boost libraries. They are one of the highest quality and best suited C++ libraries in the world, with the spirit and design of being fully compatible with the standard library and its practices.

However, Boost is not easy to love. It’s shipped with tons of inter-dependencies, even circular dependencies, and that’s only for header-only libraries (thankfully 80% of Boost is header-only). For non header-only libs, it’s a true pain. You should compile those and then link against, being careful about what you are doing.
Even if setting up Boost manually could be a bit hard, when it works it’s a pleasure to develop with it.

At biicode we have been working hard to simplify the process, to make Boost available for any C++ programmer with just an include. But this is only the start, the project has been released as open source to allow everyone contribute and help.

I hope you like it.
Boost libraries are finally supported in biicode

Working with Boost libraries

That’s what most of us do to work with Boost. There’s no easy way to change the Boost version though, or even have multiple coexistent Boost versions. In addition to the fact that the package-manager way doesn’t work on Windows.

The main purpose of biicode is to handle dependencies and improve the development workflow. That means one should take into account:

  • A user may want to work with different versions of Boost. It should be easy to switch between Boost versions during development.
  • When dealing with Standard C++, that is, with true portable C++, one should care about multiple compilers and test his/her code with all of them. It should be easy to switch Boost to work with different compilers. In our case, that means GCC, Clang, MSVC, MinGW GCC, and the different versions of each one.

That were the two main objectives I had when I started to work in Boost support for biicode. To make Boost setup portable across versions, compilers, and platforms, and at the same time make the process fully transparent to the user.

Our approach

The biicode Boost setup is very simple: Install each Boost version on a dedicated folder inside the biicode environment, and then rely on Boost’s bjam to handle the different compilers.

The setup should also handle all the installation process, which means:

  1. Download the requested Boost version if it’s not currently in the biicode environment.
  2. Bootstrap it.
  3. Build the libraries.
  4. Configure FindBoost.cmake to track the installation.

But how should that look like in user code? I was thinking about it for a long time. Actually, the current interface is just the last of a very long process of testing different approaches.
I finally ended up trying not to force the user to learn new commands. Instead, try to mimic the current Boost setup with CMake: Instead of calling find_package(Boost COMPONENTS...), call bii_find_boost(COMPONENTS...). The rest of the CMakeLists.txt is almost the same.

bii_find_boost() wraps the find_package(Boost) call by first setting up the required boost version (Steps 1 and 2 above), building the requested COMPONENTS on demand, finally calling find_package(Boost COMPONENTS ...).

A Boost example with biicode

That’s an example of the Boost.Coroutine library extracted from the Boost docs. It’s so simple, it just takes a coroutine to print the string “Hello, world!” in two steps to see how the coroutine continues its execution on consecutive calls.

This is the CMakeLists.txt file of the examples/boost-coroutine block available in our cloud:

Let’s open and run the example:

Issue with MinGW: To compile Boost.Context, MinGW depends on the Microsoft assembler. Be sure you have ml or ml64 (Depending on your platform) in your PATH. Those executables are usually shipped within Visual Studio, check the Visual Studio Directory/VC/bin/ folder.

Issue with CMake configure: Seems that CMake has problems with long-running configures. In some cases, even if the libraries were built successfully, find_package() is not able to find the Boost components. Just rerun bii cpp:configure.

Header only libraries: Boost.Spririt is a header only library. Only libraries that must be compiled should be passed to bii_find_boost(). Try with a naked bii_find_boost() call.

We currently maintain a biicode/boost block with the scripts, which has four different tracks representing the four (three) different Boost versions we have tested: master (The latest version available, currently Boost 1.57.0), 1.57.0, 1.56.0, and 1.55.0. Want to change the Boost version you want? Just go to the biicode.conf of your block and change the biicode/boost track in the requirements entry.

Refer to the docs for more info.

What’s next?

I want to see what people say about this. The main reason we released this as an open source project is to allow the community to improve it with us. This is a first working version, but I’m sure it could be improved a lot thanks to your feedback and thoughts. Check the README’s issues entry and the project issues page.
There are people who already were helping us. I specially thank Tobias Becker for his feedback on the last steps of the development. His cmakepp library is a great tool and something I want to use in our Boost scripts in the near future. cmakepp is batteries included CMake!

I think dependency management for C++ is the right way to go, and supporting Boost libraries is a great step forward.
Let’s continue working until a modern C++ development environment becomes reality.

Hope you enjoy this new feature and, as always, we look forward to read what you think. Just click on the sidebar button to try biicode, check our docsforum and/or Stackoverflow tag for questions and answers or comment below to tell us your enquiries.

Related Posts
  • Sebastian Messmer

    That is awesome news :)

    Just tried it and it works great.

    One small bug: “bii find” still displays “WARN: Can’t find block candidate for: boost/filesystem” and “bii deps” also shows the boost headers as unresolved dependencies.
    But just ignoring these warnings works – it compiles even if boost is not locally installed.

    Thanks for the great work :)

    • Manu343726

      Thanks Sebastian, I’m glad you like it. About the deps issue, it’s something we are working on. Originally the biicode deps analyzer was designed to search for code in blocks only. Since the code of boost is hosted externally to any block (In a system folder) bii is unable to find the sources.

      Remember you can post any issue you want on the repo. Actually this is one of the first points I want to mark as an issue.

    • doomdayx

      I can reproduce the problem

  • Max Galkin

    I’m trying to include Boost.Spirit libraries using your example, but I’m getting an error, how can I make it work?.. (on Windows)

    This is the console output:

    This is what I have in the CMakeLists.txt

    My include in the cpp file looks like this:

    • Manu343726

      Boost.Spririt is a header only library. Only libraries that must be compiled should be passed to bii_find_boost(). Try with a naked bii_find_boost() call.

      • Terry Eminhizer

        Thanks Manu, Max, et al., I had
        bii_find_boost(COMPONENT Spirit Required) and all heck broke loose (cmake would essentially hang, not sure if it was trying to do a full build or not, but cmake is al that was running). Maybe this will help inform some future usability tweaks. Thanks again, I’ve been on the verge of giving up on biicode multiple times now but keep finding these little nuggets of information out there to get unblocked.

  • Pingback: Sennin » Biicode()