Getting Sen¶

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.5.2 --compiler gcc-12.4.0
sh install.sh 0.5.2 --yes

~/.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.5.2-x86_64-linux-gcc-12.4.0/activate

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

Sourcing the activate file exports SEN_PREFIX, prepends the build's bin/ to PATH and to LD_LIBRARY_PATH, and points CMAKE_PREFIX_PATH at the prefix so find_package(sen) works.

To uninstall:

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

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

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.5.2 while an in-between commit reads as 0.5.2-5-gc6625265 (5 commits past tag 0.5.2, at hash c6625265).

[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()

Component selection

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

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

Per-component Conan options are deliberately not exposed (combinatorial package_id). Developers skip building specific components at the CMake step:

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

The CMake override doesn't change what Conan fetched. Components beyond mode can't be enabled this way (their deps weren't fetched).

Developer-facing flags

Examples, tests, static analysis, coverage, sanitizers, and documentation are exposed as Conan options. All default to off. Turn on what you need with -o sen/*:…=True.

Options are applied at conan install time — that's the step that generates the build files. The subsequent conan build (or a direct cmake --build) just compiles with the settings already baked in; the -D mappings above are for users invoking CMake without Conan.

# Configure a build that compiles the test suite with the address sanitizer
conan install . --profile=sen_gcc -o sen/*:with_tests=True -o sen/*:sanitizer=address --build=missing

Building the docs

with_docs=True pulls doxygen automatically, but doxygen itself needs compiler.cppstd=20 (set per-dep), which has to come from a profile rather than from the recipe. Sen ships a sen_build_docs profile that sets both, so the one-liner for docs is:

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

mkdocs and graphviz are not Conan-managed - install them via pip install -r docs/requirements.txt and your platform package manager.

Toolchain. Sen's own build gets its tools as Conan tool requirements: CMake, Ninja, GTest — and Node.js 22 whenever the jsonrpc component is enabled (any mode above basic), because the build generates the @sen/client TypeScript types, installs its npm dependencies, and bakes the Web Explorer bundle into the binary. 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. Don't install Node for the build; the pinned toolchain version comes with conan install. (The TS packages' dev loops — npm run dev, vitest on the host — do use your own Node >= 22; see components/jsonrpc/clients/typescript/README.md.)

Network. The first conan install/conan build fetches 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 skip the web stack entirely: build -o "sen/*:mode=basic", or stay in full mode and pass -DSEN_BUILD_JSONRPC_TS_CLIENT=OFF -DSEN_BUILD_WEBEXPLORER=OFF at the CMake step.

Time. The first full-mode build compiles every third-party dependency plus the whole tree; on a typical developer machine expect on the order of half an hour to an hour. Subsequent builds are incremental. ccache shortens rebuilds — CI simply prepends the ccache masquerade directory to PATH before building.

Windows. The browser stack is currently unverified on Windows (standard tests are disabled there, see SEN-1725); the C++ tree builds with MSVC.

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