BDE: Bloomberg's C++ foundation libraries, built by bbs_build rather than plain cmake

Four libraries in one repository, layered by abstraction level

BDE stands for Basic Development Environment, and the repository holds what Bloomberg describes as a set of foundational C++ libraries used at Bloomberg. The contents are grouped into four named collections: BSL, the Basic Standard Library; BDL, the Basic Development Library; BAL, the Basic Application Library; and BBL, the Basic Business Library.

The naming implies a dependency ladder, with the most general components in the layer closest to the standard library and the domain oriented code highest up. The project topics reinforce the emphasis: allocators, cpp, cpp-library, cpp11 and polymorphic-allocators. Allocation is not an incidental detail here, it is one of the areas the libraries are known for.

The distribution is Apache License 2.0, with the LICENSE file at the top of the source tree. That matters more than it might for a corporate code drop, because Apache 2.0 carries the same patent grant and NOTICE obligations as any other Apache project.

The build system is not in this repository

This is the single most important fact for anyone evaluating BDE. The README states that BDE uses a build system based on cmake and that the build system is located in the BDE tools repository, not here.

In practice you clone a second repository and put its bin directory on your PATH:

$ git clone https://github.com/bloomberg/bde-tools.git
$ export PATH=$PWD/bde-tools/bin:$PATH      # add bde-tools to the 'PATH'
$ git clone https://github.com/bloomberg/bde.git
$ cd bde

A CMakeLists.txt does exist at the root of the repository, alongside a conanfile.py, a Doxyfile, a Jenkinsfile and a Jenkinsfile.conan. Those support alternative consumption paths. But the documented build path runs through bbs_build, a command that comes from bde-tools, so a vanilla cmake invocation is not what the project expects.

Configuring with opt_dbg_64_cpp17 and a build directory you export yourself

Configuration takes two steps. The first is to tell the tooling where build output goes, and the second is to name a build target. Both are plain shell assignments and a single command:

$ export BDE_CMAKE_BUILD_DIR=$PWD/_build   # configure the build directory
$ bbs_build configure -u opt_dbg_64_cpp17

The target name encodes the configuration: optimized, with debug info, 64 bit, targeting C++17. That naming scheme is the build system's vocabulary, and it is where a team new to BDE will first feel the difference from a stock CMake workflow. Configuration is not a one time thing here in the usual sense, because the configuration lives in the target name rather than in a cache file you edit.

The prerequisites are CMake version 3.12 or later, Ninja (recommended) or GNU Make, and Python. The README adds a note about Python: it is used by the build helpers bde_build_env.py and cmake_build.py, but is not strictly needed to build BDE. So the Python requirement is a convenience of the tooling rather than a hard dependency of the libraries.

Three build modes, and the test drivers are off by default

After configuring there are three forms of the build command, and the difference between them is the test drivers.

$ bbs_build build

builds the libraries only. To compile the test drivers without running them:

$ bbs_build build --test build

and to build and run them:

$ bbs_build build --test run

That default matters for time budgets. A contributor or integrator who runs bbs_build build gets a working library and no test execution, which is the fast path. Anyone validating behaviour needs the third form, and on a codebase this size the difference is not marginal.

The Bloomberg LP internal instructions are identical apart from the clone URLs, which point at a bbgithub remote rather than github.com. Everything after the clone step, the PATH export, the build directory and all three build forms, is the same command sequence.

Samples show the intended usage, including allocators and object pools

The samples/ directory is the fastest way to see what the libraries expect from a user. There is a standalone sample file, bsl-vector-sample.m.cpp, alongside complete programs: samples/buffer_allocator/, samples/object_pool/, samples/read_lines/, and samples/customer/.

The names tell you what the libraries are built around. A buffer allocator sample and an object pool sample both point at memory management as a first class concern, which lines up with the allocators and polymorphic-allocators topics. The read_lines sample is closer to I/O, and customer is the one that looks like domain usage.

There is also a benchmarks/ directory at the top level, plus thirdparty/ for vendored dependencies. The build infrastructure is more visible here than in most open source C++ drops, which is consistent with a set of libraries whose primary consumers are internal.

Packaging and CI paths exist alongside the CMake build

Beyond bbs_build there are several other entry points in the tree. conanfile.py means the libraries can be consumed as a Conan package. debian/ suggests Debian packaging is maintained in tree. Jenkinsfile and Jenkinsfile.conan cover two flavours of continuous integration, presumably one per consumption path.

There is also a Doxyfile, and the README badges point at an internal Alexandria Doxygen site, so generated API documentation is produced from this source tree.

The repository also carries several development and static-analysis configuration files. These are harmless to a consumer but relevant to a contributor, because they describe an internal workflow that is only partly open.

What adopting BDE actually costs

The licensing question is straightforward: Apache 2.0 with the LICENSE file at the top of the source tree, and the same obligations you would accept for any Apache 2.0 dependency. No copyleft attaches to code that links against it.

The cost is structural. Adopting these libraries means accepting the build system, and the build system lives outside the repository and must be on your PATH for every build. A mature CMake pipeline and CI that expects a single repository checkout has to add a second repository and a PATH assumption. The conanfile.py offers a way around that for consumption, but the README does not document it, so you are reading the Conan file yourself.

For context on cadence: the last push was on 2026-10-14, and there are no GitHub releases. So the code is being worked on actively, but the only version signal available is the commit history rather than a tag.

Editorial conclusion

Adopt BDE if you are writing C++ and want Bloomberg's foundational libraries, and if you are prepared to put the bde-tools repository on your PATH and drive builds through bbs_build. Do not adopt it if you need a plain cmake build, because the build system lives in a separate repository rather than in the CMakeLists.txt at the root. Verify first that CMake 3.12 or later, Ninja or GNU Make and Python are present, and decide before you start whether you will build the test drivers, since bbs_build build skips them by default and bbs_build build --test run is a much longer operation.

Frequently asked questions

Official sources

1. bloomberg/bde on GitHub
2. Issues
3. License: Apache-2.0
4. README