Building Sen from source¶

Most users do not need to build Sen themselves; the Conan package and the quick installer cover the common paths. Build from source when you want to track main, patch Sen for local development, or run on a platform without a release artifact.

Prerequisites¶

Always required

• A C++17 compiler (GCC 9.2.1+, Clang, or MSVC). Sen targets the C++17 language standard. The CI builds with GCC 12, Clang 20 and MSVC 194; other versions are untested in the CI.
• Conan 2.x.

pipx install conan
pipx ensurepath

Not pip install: current Debian and Ubuntu refuse it with externally-managed-environment. ensurepath needs a new shell to take effect.

• On Linux, objdump — from binutils. It is needed at install time, not build time: the install rules resolve which third-party shared objects the binaries actually need, and CMake uses objdump to read them. Without it cmake --install fails long after a successful build. It arrives with GCC, so a normal toolchain already has it; a minimal Conan-only image may not.

• On Linux, a couple of system libraries that Conan can't ship (pulled in by SDL2 / imgui via Sen's requirements() block in conanfile.py). On Debian / Ubuntu:

sudo apt install libxext-dev pkg-config

Equivalents on RHEL / Fedora / SUSE: libXext-devel (or libxext-devel) plus pkg-config. Conan can also install these for you if you set tools.system.package_manager:mode=install in your profile, but pre-installing them is simpler and less intrusive.

When you go through the Conan-driven path below, Conan downloads CMake (3.31.10), Ninja (1.13.2) and GTest into its own cache as tool_requires, plus Node.js 22 whenever the jsonrpc component is enabled, which is any mode above basic. None of those need a system install, and you should not install Node yourself: the build uses the pinned one to generate the @sen/client TypeScript types, install its npm dependencies and bake the web explorer bundle into the binary. The TypeScript packages' dev loops, npm run dev and vitest on the host, do use your own Node 22 or newer; see components/jsonrpc/clients/typescript/README.md.

Building the third-party packages from source is different: their recipes use the system's cmake and pkg-config, so have both installed before the first conan install.

Required only if you skip Conan

• CMake 3.21 or newer (the project minimum).
• Ninja (other generators work, but the bundled profiles assume Ninja).

Clone the repository:

git clone https://github.com/airbus/sen.git
cd sen

Conan-driven build (recommended)¶

Step 1: install the profile Sen ships. It pins the compiler, the C++ standard and Ninja, so your build matches CI and matches the commands on the rest of these pages:

conan config install -tf profiles .conan/profiles/sen_gcc

Use sen_clang or sen_msvc if that is your compiler.

conan profile detect writes a profile describing your own machine and builds Sen too, but it selects a different generator and different preset names, so the commands here and under Running the tests will not match what it produces.

Step 2: resolve dependencies and build:

conan install . --profile:all=sen_gcc --build=missing
cmake --preset conan-gcc-release
cmake --build --preset conan-gcc-release

Always pass --build=missing. Without it, Conan refuses to build any dependency that doesn't already have a matching binary in its cache.

The first run downloads and builds Sen's third-party dependencies; subsequent runs reuse Conan's cache.

The preset name comes from tools.cmake.cmake_layout:build_folder_vars, not from the compiler you have. A detected profile does not set it, so the preset is conan-release. The bundled profiles do set it, so building with one of those gives conan-gcc-release, conan-clang-release and so on. List what you actually have with:

cmake --list-presets

conan install writes these into CMakeUserPresets.json at the repository root, so VS Code, CLion and Visual Studio offer them once you open the folder. Run the install step before opening the project, or the IDE finds no presets to list.

conan config install -tf profiles .conan/profiles/sen_gcc
conan install . --profile:all=sen_gcc --build=missing

Build options¶

mode is the Conan-level switch; it picks which components compile and which dependencies Conan fetches.

conan install . --profile:all=sen_gcc -o sen/*:mode=basic --build=missing

Per-component Conan options are deliberately not exposed, because they multiply the package ids. Skip individual components at the CMake step instead:

conan install . --profile:all=sen_gcc --build=missing
cmake --preset conan-gcc-release -DSEN_BUILD_TRACY=OFF -DSEN_BUILD_EXPLORER=OFF

That does not change what Conan fetched, so components beyond the chosen mode cannot be turned on this way: their dependencies are not there.

Developer-facing flags. Examples, tests, static analysis, coverage, sanitizers and documentation are Conan options, all off by default.

They apply at conan install, the step that generates the build files. The later conan build or cmake --build compiles with them already baked in; the -D column is for driving CMake without Conan.

sanitizer needs a clang profile. The instrumentation flags exist only in the build's clang branch, so asking for a sanitizer with sen_gcc or sen_msvc stops the configure instead of producing a binary with nothing to report.

# tests compiled with the address sanitizer
conan install . --profile:all=sen_clang -o sen/*:with_tests=True -o sen/*:sanitizer=address --build=missing

Building the documentation. with_docs=True pulls doxygen, which itself needs compiler.cppstd=20 set per-dependency, and that has to come from a profile rather than the recipe. Sen ships one:

conan install . --profile:all=sen_build_docs --build=missing

mkdocs and graphviz are not Conan-managed. graphviz comes from your platform package manager; the pinned Python set goes in a virtual environment, because current Debian and Ubuntu refuse to install it into the system Python:

python3 -m venv .venv-docs
.venv-docs/bin/pip install -r docs/requirements.txt

A virtual environment rather than pipx because the file pins eleven plugins that mkdocs imports, and they have to share its environment. python3-venv is a separate apt package and python3 -m venv fails without it.

What the build needs from the network, and how long it takes¶

The first conan install and conan build fetch from Conan Center and, for the browser stack, from the npm registry during the build itself (npm ci). Behind a proxy, make both reachable, or leave the web stack out with -o "sen/*:mode=basic", or stay in full mode and pass -DSEN_BUILD_JSONRPC_TS_CLIENT=OFF -DSEN_BUILD_WEBEXPLORER=OFF -DSEN_BUILD_MCP_GATEWAY=OFF at the CMake step. The web explorer and the MCP gateway both bundle @sen/client, so each needs turning off by name or CMake stops with an error.

A first full-mode build compiles every third-party dependency plus the whole tree: expect half an hour to an hour. Later builds are incremental. Sen's own tree wires ccache in through CMAKE_<LANG>_COMPILER_LAUNCHER whenever it is installed, with nothing to configure. Dependencies build inside their own projects and never see that, so to cache those too, put your distribution's ccache shim directory (/usr/lib/ccache on Debian and Ubuntu) ahead of the compilers on PATH for the conan install step only, which is what CI does.

On Windows the C++ tree and the browser stack both build with MSVC, and projects run on it. The test suite runs there too, on fewer configurations than Linux.

Direct CMake build¶

Once conan install has populated the build folder with toolchain files, you can drive CMake directly. This is useful when iterating on Sen itself without re-running Conan each time.

conan install . --profile:all=sen_gcc --build=missing  # generates the preset under build/
cmake --preset conan-gcc-release                       # configures the build
cmake --build --preset conan-gcc-release               # compiles

The preset name is not the same as the Conan profile name. Conan generates presets named conan-<compiler>-<build_type> when the profile sets tools.cmake.cmake_layout:build_folder_vars, and just conan-<build_type> otherwise.

Using the Sen you just built¶

A package generated by sen package init does find_package(sen REQUIRED) and looks under $SEN_PREFIX/cmake. A build tree has no such layout, so pointing SEN_PREFIX at build/gcc/Release does not work. Install it first:

cmake --install build/gcc/Release --prefix ~/sen-local
export SEN_PREFIX=~/sen-local

From there every command in Create your first package and in the tutorials works unchanged, because that is the layout they assume.

cmake -S . -B build -G Ninja \
  -DCMAKE_PREFIX_PATH="$SEN_BUILD;$SEN_BUILD/generators" \
  -DCMAKE_BUILD_TYPE=Release

Building against a local Sen (Conan editable mode)¶

Editable mode lets a project that depends on Sen build against your working copy, without running conan create after every change.

Add your checkout to Conan's editable list. The version has to match the one the consumer project requires:

conan_channel=$([ -n "$TAG_NAME" ] && echo "stable" || echo "devel")
conan editable add . --user=airbus --channel=$conan_channel

conan editable list shows what is currently registered. Then run conan install in the consumer project: Sen appears as Editable in the dependency list, and the consumer compiles against your local build. To go back to the packaged version:

conan editable remove .

Running the tests¶

ctest --preset conan-gcc-release

To run a single test target by name pattern:

ctest --preset conan-gcc-release -R <pattern>

Common first-run errors¶

What sen --version reports from a source build¶

A binary you built yourself prints a bare commit hash, not a version number:

$ sen --version
0271e1ba

That is correct behavior, not a broken build. The string is fixed at configure time from git describe --tags --always, so it reports a version only when a tag is reachable from the commit you built. Sen's release tags live on the release/* branches and not on main, so nothing built from main has one, and --always falls back to the hash. A release you install through the installer prints 0.6.0, because it was built from a tagged commit.

There is no flag that changes this. If you need a build to report a version, build from a tag.

Troubleshooting¶

• First-build memory pressure: building the dependency graph cold needs a few GB of RAM, and compiling defaults to one job per CPU. Add -c tools.build:jobs=<N> to conan install and conan build to limit that on a constrained machine.

For other questions, the Troubleshooting guide and the FAQ cover the common cases. Bug reports are welcome via the project's issue tracker.