You wanted Boost via Meson subprojects? You got it! (sorta)

In the previous blog post we saw a way to build SDL transparently as a Meson subproject. In the discussion that followed I got a question on whether you could consume Boost in the same way. This is an interesting question, because Boost is a, let's say, challenging dependency. It is very big and set up in an unusual way. As an example I would estimate that the single fact that they don't ship Pkg-Config files has cost Meson developers tens of hours of unnecessary troubleshooting. Having something simpler and more reliable would be welcome.

To test this out I created an MVP program that uses Boost's flat map from the container library and then added dependencies until it worked. The actual code can be downloaded here (tested on Linux, VS and Mac). The main program's basic build definition is as simple as the SDL program's was:

boost_container_dep = dependency('boost-container')
executable('boosttest', 'boosttest.cpp',
           dependencies: [boost_container_dep])

The Boost container dep is specified in the container library's build file:

boost_container_dep = declare_dependency(

  include_directories: 'include',
  dependencies: [...])

As this is a header-only library, the only thing it needs to do is to expose the header dir. The dependencies keyword argument lists all the other dependencies that are needed to build code that uses the container library. These are move, assert, static_assert, intrusive, core and config. Their build files are almost identical to this one. No code changes were needed. The total LoC of meson.build files for this entire setup is 42. Which is apt.

Making it better

The main reason for this low line count is the fact that the Meson build definition do a lot less than the original ones. They do a lot are highly configurable, which might also explain why Boost's conversion to CMake has taken several years and is still ongoing. A lot of that effort is taken by things like documentation, but the actual build is also more complicated as it provides for more stuff. Here are two examples and an outline of how they would be implemented in Meson.

Built libraries

Some Boost libraries are header-only, others require some code to be built and linked against. Suppose we have a header-only dependency. Its dependency object would be defined like this:

foo_dep = declare_dependency(include_directories: 'include')

Converting that to contain a library component would be done like this:

foo_lib = library(...)

foo_dep = declare_dependency(include_directories: 'include',

                             link_with: foo_lib)

Basically you build the library and then tell users to link to that. This is pretty much what the SDL build definitions did. The library can be shared or static, they both work the same way.

Compiler flags needed for using the dependency

Some of the libraries seem to require that users of the library must specify some compiler command line arguments. These might or might not be the same ones that are used to build the library components themselves. This is natively supported.

foo_dep = declare_dependency(include_directories: 'include',

                             compile_args: ['-DUSING_FOO'])

How much work would it be to convert all of Boost?

It depends, but quite a lot in any case. Boost is very big. If one attempts to reach feature parity with the current build system it would be a very, very big effort. I'm told that there are parts of Boost that have circular dependencies between projects and Meson does not support those (as in: they are inexpressible). Meson's HP-UX support is also still a work in progress (or, to be more exact, a work not in progress, at least as far as I'm aware of).

Doing a simple conversion that only needs to deal with the code on common platforms, on the other hand, would be doable. It would require a small team of dedicated people, because trying to do it alone would just lead to a massive burnout, but it could be done.