Getting Sen¶

How you get Sen depends on what you want to do:

Try Sen quickly on Linux without setting up Conan: use the quick installer.
Use Sen as a dependency in your project: use the Conan package.
Install Sen on a machine without an internet-facing toolchain (Windows, air-gapped Linux): use the release zip packages.
Compile Sen yourself, to track main or to run on a platform with no release artifact: see building from source.

Quick install (Linux)¶

Sen provides an installer script that does this for you. It is plain POSIX sh, needs no Conan, and installs under ~/.sen rather than into system directories, refusing to run as root.

Releases publish x86_64 Linux and amd64 Windows archives only. The script picks the asset that matches your host, so on any other architecture, arm64 Linux included, it finds nothing to download and stops. Build from source there.

The installer needs curl, tar and sha256sum. The Linux archives need glibc 2.35 or newer and GCC 12's libstdc++, so Ubuntu 22.04 and later or Debian 12 and later; RHEL 9 is too old. Building your own package against the install also needs CMake and a C++17 compiler.

1. Install:

curl -sSf https://raw.githubusercontent.com/airbus/sen/main/resources/installer/install.sh | sh -s -- 0.6.0

2. Activate (and append the same line to your shell rc to load Sen on every new shell):

. ~/.sen/current/activate          # bash / zsh
source ~/.sen/current/activate.fish # fish

3. Check:

sen --version

What the installer prints

  Sen Installer  v0.2.0
  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

  Configuration
    Version    0.6.0
    Toolchain  gcc 12.4.0
    Arch / OS  x86_64-linux
    Prefix     /home/alice/.sen/0.6.0-x86_64-linux-gnu-12.4.0

  ✓ Downloaded sen-0.6.0-x86_64-linux-gnu-12.4.0-release.tar.gz (42M)
  ✓ Verified sha256 checksum
  ✓ Extracted into /home/alice/.sen/0.6.0-x86_64-linux-gnu-12.4.0
  ✓ Cached CLI completions  (bash, zsh, fish)
  ✓ Wrote integrity manifest
  ✓ Wrote activate scripts
  ✓ Refreshed cached installer
  ✓ Updated 'current' to  0.6.0-x86_64-linux-gnu-12.4.0

  ──────────────────────────────────────────────────────────────────────

  ✓ Sen 0.6.0-x86_64-linux-gnu-12.4.0 installed.

  Activate this build:
    bash/zsh   . /home/alice/.sen/current/activate
    fish       source /home/alice/.sen/current/activate.fish

The prefix carries the compiler's own identifier, gnu, where the Toolchain line prints gcc.

The checksum line is the archive checked against the release's SHA256SUMS. Releases before 0.7.0 published none and print a note instead. A checksum that fails stops the install.

Different versions, toolchains, non-interactive

Run with no arguments to list the available releases:

curl -sSf .../install.sh | sh

A release with multiple toolchains (gcc, clang, ...) opens an interactive menu. Skip it by pinning a toolchain explicitly, or run fully non-interactively:

sh install.sh 0.6.0 --compiler gcc-12.4.0
sh install.sh 0.6.0 --yes

Switching versions and pinning a specific build

~/.sen/current is a symlink to the most recently installed build. Running sh install.sh <other-version> flips the symlink, even if that version was already installed.

To pin a specific build, source the per-build path directly instead of current/:

. ~/.sen/0.6.0-x86_64-linux-gnu-12.4.0/activate

The activate scripts strip any prior ~/.sen/-rooted entries from PATH and friends, so re-sourcing or switching is idempotent.

What activate sets, and how to uninstall

Sourcing the activate file exports SEN_PREFIX, prepends the build's bin/ to PATH and to LD_LIBRARY_PATH, and prepends <prefix>/cmake to CMAKE_PREFIX_PATH so find_package(sen) works. The /cmake suffix is the part that matters; see below.

To uninstall:

rm -rf ~/.sen/<build-id>     # one build
rm -rf ~/.sen                # everything

Then drop the source ...activate line from your shell rc.

For environment variables, the security model, and the full set of options, see resources/installer/architecture.md.

Using Sen in your project (Conan)¶

Sen ships as a Conan package. Publication on Conan-Center is on the roadmap; until then there is no remote to resolve it from, so you put it in your local Conan cache yourself:

git clone https://github.com/airbus/sen.git
cd sen
git checkout 0.6.0
conan create .

Check out the release tag first. The recipe takes its version from git describe --tags, and the tags are on the release/x.y.x branches rather than on main, so a fresh clone left on main gives you sen/<commit hash> instead of sen/0.6.0.

conan create . uses your default Conan profile. If you have never used Conan, run conan profile detect once first. Sen's own profiles in .conan/profiles/ are for building Sen itself: they fix the operating system and pin compiler versions and executable names, so they are not a starting point for your machine.

The recipe sets cmake_find_mode = "none" (in conanfile.py), so Conan does not generate a synthetic senConfig.cmake for downstream consumers. Instead, your build picks up Sen's own <prefix>/lib/cmake/sen/sen-config.cmake via the CMAKE_PREFIX_PATH that CMakeDeps populates: find_package(sen) "just works" once the toolchain file is loaded.

Add a Conan configuration file (conanfile.txt or conanfile.py) at the top level of your project and list Sen as a dependency.
Make sure you have a Conan profile that matches your host. If this is your first time using Conan, run conan profile detect once: it inspects your installed compiler, OS, and architecture and writes ~/.conan2/profiles/default. Without a profile, the next step errors with Profile 'default' doesn't exist.
Resolve, build, and install the dependencies before running CMake:

conan install . --profile:all <your_conan_profile> --build=missing

Always pass --build=missing. Without it, Conan refuses to build any dependency that doesn't already have a matching binary in its cache, which is rarely what you want on a fresh checkout.

Conan set-up

Install or upgrade Conan with:

pipx install conan
pipx ensurepath

pipx rather than pip: current Debian and Ubuntu refuse pip install into the system Python with externally-managed-environment. ensurepath puts ~/.local/bin on PATH, and it takes a new shell before conan resolves. Later, pipx upgrade conan.

Create a profile for your environment in <HOME>/.conan2/profiles:

~/.conan2/profiles/gcc15

[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=17
compiler.libcxx=libstdc++11
compiler.version=15
os=Linux

[conf]
tools.build:compiler_executables={"c": "gcc-15", "cpp": "g++-15"}

Sen recommends Ninja Multi-Config as the CMake generator. Set it once in <HOME>/.conan2/global.conf:

~/.conan2/global.conf

tools.cmake.cmaketoolchain:generator="Ninja Multi-Config"

The Sen repository ships ready-to-use profiles in .conan/profiles. sen_gcc and sen_clang pin the compilers CI builds with and otherwise follow the machine you run them on; sen_msvc pins Windows on x86_64. Use one of those three; there is no architecture to choose.

The suffixed names exist for CI and the devcontainer, which compose one from the compiler and the machine's architecture and copy it into place as the default profile. Of them only sen_gcc_arm changes anything — it pins armv8, which is what keeps .conan/conan.lock from depending on whichever machine regenerated it. The rest add nothing to the profile they include. Install them with:

conan config install -tf profiles .conan/profiles/

Install the whole folder, not one file. The three base profiles, sen_gcc, sen_clang and sen_msvc, are self-contained and do work on their own. The other five, the four architecture variants plus sen_build_docs, are an include of their base plus what they override, so installing sen_gcc_x86 by itself fails with Profile not found: sen_gcc. Note that the error names the base it could not find, not the profile you asked for.

For different compiler versions, prefer conan profile detect over the bundled profiles. See Building Sen from source for the full walk-through.

Example conanfile

Replace x.y.z with the Sen version you want. The recipe derives its version from git describe --tags, so a tagged release reads as 0.6.0 while an in-between commit reads as 0.6.0-5-gc6625265 (5 commits past tag 0.6.0, at hash c6625265).

conanfile.txtconanfile.py

[requires]
sen/x.y.z

[layout]
cmake_layout

[generators]
CMakeToolchain
CMakeDeps

from conan import ConanFile
from conan.tools.cmake import CMake, cmake_layout

class ProjectConfig(ConanFile):
    settings = "os", "arch", "compiler", "build_type"
    generators = "CMakeDeps", "CMakeToolchain"

    def requirements(self):
        self.requires("sen/x.y.z")

    def layout(self):
        cmake_layout(self)

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()

Manual release packages¶

For Windows or environments where the quick installer is not an option, download the release archive for your platform from the Releases page and extract it anywhere. The extracted directory is <sen_path> in the snippets below.

Each platform has several archives, and which one you want depends on what you are doing.

Archive	The question it answers
`-release`	what do I run
`-symbols`	what do the frames in my release crash say
`-relwithdebinfo`	how do I step through Sen's own code
`-debug` (Linux only)	what do Sen's own internal checks say

Take -release. It is the build to run and the only one most people need. Keep -symbols beside it if you expect to read a crash: together they turn a crash in the build you actually run into named frames with files and lines. The symbols archive is not needed to run Sen and is a much larger download, so fetch it when you need it.

-relwithdebinfo is a different build of the same program, optimised but carrying debug information, for stepping through Sen in a debugger where the release build's inlining gets in the way. Its symbols do not describe the -release binaries.

-debug is not the release build with more symbols, it is a different program: Sen's internal checks compile in, and the exception type thrown on an internal error changes with them, so code that catches by a concrete type behaves differently. Reach for it to reproduce a problem under Sen's own checking, not to read a crash that happened in a release build, because the crash you are reading may not be the crash it produces. There is no Windows -debug; a Windows debug build would have to link the debug runtime, and Sen's dependencies are built with the release one.

The installer takes -release unless you ask for another: --symbols for the release build's debug information, --debug-symbols for the -relwithdebinfo build, or --debug for the unoptimised one.

Reading a crash¶

Extract -symbols anywhere and point the debugger at it when it starts:

gdb -iex "set debug-file-directory <symbols_path>/lib/debug" <sen_path>/bin/sen core

It has to be -iex and not -ex. The debugger looks for separate debug information while it loads the binary, so the same setting arriving afterwards does nothing at all and the frames come back unnamed, which looks like a problem with the symbols and not with the ordering.

A debug file sitting next to the binary it belongs to needs no configuration, because each binary records the name of its own.

On Windows the debug information lives in .pdb files. Extract -symbols over the extracted -release directory so each .pdb lands beside the binary it belongs to, which is where a debugger looks first.

LinuxWindows

export SEN_PREFIX=<sen_path>

# Sen binaries on PATH. Sen finds its own shared libraries through its run path, so this is all
# that running sen needs.
export PATH="$SEN_PREFIX/bin:$PATH"

An application you build against Sen has to find those libraries itself. Give it a run path of its own, or tell the loader where to look:

# Shared libraries and archives are under <prefix>/lib (CMAKE_INSTALL_LIBDIR). Releases
# before that split put them in <prefix>/bin, so both are named here and whichever the
# release you downloaded does not have costs the loader nothing.
export LD_LIBRARY_PATH="$SEN_PREFIX/lib:$SEN_PREFIX/bin:$LD_LIBRARY_PATH"

set SEN_PREFIX=<sen_path>

rem Sen binaries and DLLs on PATH
set PATH=%SEN_PREFIX%\bin;%PATH%

In your project's CMakeLists.txt, point CMake at the prefix and pull Sen in with find_package:

list(APPEND CMAKE_PREFIX_PATH "$ENV{SEN_PREFIX}")
find_package(sen REQUIRED)

Sen installs its CMake config under <prefix>/lib/cmake/sen/sen-config.cmake, which CMake's standard search reaches from the prefix. Older releases installed it under <prefix>/cmake/sen, which the search does not reach; against one of those, append /cmake to the prefix path.

Building from source¶

If you want to compile Sen yourself (to track main, patch the code, or run on a platform without a release artifact), see Building Sen from source. It has the profile to install, the component modes, the developer flags, what the build needs from the network, and how long a first build takes.

If your editor supports devcontainers, the repository ships one under .devcontainer/. It builds the same environment the pipeline uses, from tools/ci/Dockerfile, so you do not have to install compilers or Conan yourself.

For enabling and running the test suite, see Running the tests.

Next steps¶

Sen is installed. The quickest way to see it working is to generate a package, build it and run it, which both routes below walk through.

The tutorials: Tutorial 1 goes from sen package init to an object you can watch changing in the term.
Create your first package: the same ground as reference, explaining what sen package init generates and what each file is for.