Documentation
- ๐ Welcome to the CMake RE Documentation
- ๐ Getting started with CMake RE for C++
- ๐ฆ Getting started with CMake RE for Rust (alpha)
- Key Principles and Goals
- ๐ชฉ Developer Machine Digital Twin
- ๐ฉ๐ผโ๐ป cmake-re --help | Command Line Reference
- ๐ฆ L1 Build cache
- ๐ฆ L1 Build Cache Sharing
- ๐ฆ FetchContent() and Package Managers
- ๐ป Environments
- ๐ป Environment Layers Specifications
- ๐ป Self-hosted runners
- Authentication
- Ignore and exclude - Caching and Mirroring
- Accessing hermetic builds folders
- Continuous integration
- Environment variables
- ๐ก๏ธ Data Security and Privacy
- tipi - ๐ฎ EXPERIMENTAL - CMakeLists.txt Generator
- tipi - ๐ฎ EXPERIMENTAL - Getting started with tipi CMakeLists generator
- tipi - Compile options
- tipi - Integrated Package Manager
- tipi - Running tests
- tipi - IDE Integration
๐ป Environments
A CMake RE environment consist of 2 elements:
- CMake toolchain file, as passed via
-DCMAKE_TOOLCHAIN_FILE=
- OS image specification in a
.pkr.js/
folder :
- Dockerfile
- Virtual Machine Image
The OS images are described by pkr.js
folders and files to provide reproducible, containerized hermetic builds.
They can be used on a local machine with cmake-re
or on a remote build orchestrator ( e.g. tipi.build ).
Generalization : Content Adressable Toolchains
Environments are passed via -DCMAKE_TOOLCHAIN_FILE=
to cmake-re
, but the real CMAKE_TOOLCHAIN_FILE used for the build will be substituted for another location generalized by cmake-re
.
Generalization in cmake-re
means that any -DCMAKE_TOOLCHAIN_FILE=<tolchain-name>.cmake
passed has it's parent directory transferred to a fixed, centralized and content-addressable location on every system, the path is based on the folder content.
The toolchain's fingerprint is then used as a (shareable) cache-key across projects.
A Generalized toolchain is a toolchain and it's accompanying environment specification cleaned up of any developer system-specific elements. Essentially this guarantees that:
- Toolchains will always be located based on a Content Addressable location
- File times won't affect the environment build process ( e.g. To guarantee cache use on OS Image / Docker creation )
Configurability
Because generalization essentially picks all files in the toolchain directory, while not necessary, it's possible to configure it with <toolchain-name>.layers.json files
to better compose and isolate toolchains from each other even when they are located right next to each other.
OS Image File Lookup Rule
The environments specifications are pointed to for a build via the cmake-re
-DCMAKE_TOOLCHAIN_FILE=<toolchain>.cmake
command line parameter.
OS Image are described as .pkr.js/
folders. In order to determine the OS Image cmake-re
looks for the most specialized OS Image it can find picking :
- The
<toolchain>.pkr.js
with the exact same name than<toolchain>.cmake
- The next
.pkr.js
file which shares the most starting character with<toolchain>
in the same folder. - If this doesn't yield any results, it perfoms the same search in the default environments directory
/usr/local/share/.tipi/<distro>/environments/
(orC:\.tipi\<distro>\environments\
).
OS Image Lookup Example
Given the following example set of toolchain files :
โโโ environments
โโโ linux-cxx17.cmake
โโโ linux-cxx20.cmake
โโโ linux-cxx23.cmake
โโโ linux.pkr.js
โ โโโ linux.pkr.js
โโโ linux-cxx23.pkr.js
โโโ linux-cxx23.Dockerfile
โโโ linux-cxx23.pkr.js
When cmake-re
is provided -DCMAKE_TOOLCHAIN_FILE=environments/linux-cxx23.cmake
the OS Image description environments/linux-cxx23.pkr.js/
will be picked, while if -DCMAKE_TOOLCHAIN_FILE=environments/linux-cxx17.cmake
or -DCMAKE_TOOLCHAIN_FILE=environments/linux-cxx20.cmake
is provided the build will run within the environment described by environments/linux.pkr.js/
.
Because in this example there are no environments/linux-cxx23.layers.json
any change to linux.pkr.js
would also affect rebuilding any code dependent linux-cxx23.cmake
, if this isn't desired it's possible to add linux-cxx23.layers.json
to isolate environments, while still giving possibility to compose common cmake modules.
Default Environments
Officially supported environments can be found in the tipi-build/environments GitHub repository.
They are unpacked in the default environments directory /usr/local/share/.tipi/<distro>/environments/
(or C:\.tipi\<distro>\environments\
).
Custom Environments
Requirement: The environment shall contain a
cmake-re
remote rpc server This can be setup as in the following example.
To get the minimum required to bootstrap an hermetic build, a ready-made setup script for your environment can be setup for use with CMake RE :
System Family | CMake RE remote server setup script |
---|---|
Centos, Redhat | https://raw.githubusercontent.com/tipi-build/cli/master/install/container/ubuntu.sh |
Ubuntu, Debian | https://raw.githubusercontent.com/tipi-build/cli/master/install/container/centos.sh |
Custom Docker Environment Example
These scripts could be used as follow to make a build environment based on Ubuntu 22.04 :
environments/linux.pkr.js/linux.Dockerfile
FROM ubuntu:22.04
ENV TIPI_DISTRO_MODE=all
ARG DEBIAN_FRONTEND=noninteractive # avoid tzdata asking for configuration
# Install needed tools
RUN apt update -y && apt install -y curl
RUN curl -fsSL https://raw.githubusercontent.com/tipi-build/cli/master/install/container/ubuntu.sh -o ubuntu.sh && /bin/bash ubuntu.sh
EXPOSE 22
environments/linux.pkr.js/linux.pkr.js
NOTE:
cmake-re
will pull the imagetipibuild/testapp-cmake-re-containerized
and use it if it exists, if it doesn't exists or is outdated theenvironments/linux.pkr.js/linux.Dockerfile
will be used to create or update it.
{
"variables": { },
"builders": [
{
"type": "docker",
"image": "tipibuild/testapp-cmake-re-containerized:{{tipi_cli_version}}",
"commit": true
}
],
"post-processors": [
{
"type": "docker-tag",
"repository": "linux",
"tag": "latest"
}
]
,"_tipi_version":"{{tipi_version_hash}}"
}
Found an error or want to add more info? Write an issue or contribute changes to this documentation at tipi-build/docs on