build: Add git-lfs to Nix images (#7561)

Co-authored-by: Ed Hennis <ed@ripple.com>

.github/scripts/strategy-matrix/linux.json

@@ -1,5 +1,5 @@
 {
-  "image_tag": "sha-63ffdc3",
+  "image_tag": "sha-fe4c8ae",
   "configs": {
     "ubuntu": [
       {
@@ -68,7 +68,7 @@
         "compiler": ["gcc"],
         "build_type": ["Release"],
         "arch": ["amd64"],
-        "image": "ghcr.io/xrplf/xrpld/packaging-debian:sha-63ffdc3"
+        "image": "ghcr.io/xrplf/xrpld/packaging-debian:sha-577d745"
       }
     ],
 
@@ -77,7 +77,7 @@
         "compiler": ["gcc"],
         "build_type": ["Release"],
         "arch": ["amd64"],
-        "image": "ghcr.io/xrplf/xrpld/packaging-rhel:sha-63ffdc3"
+        "image": "ghcr.io/xrplf/xrpld/packaging-rhel:sha-577d745"
       }
     ]
   }

.github/workflows/build-nix-images.yml

@@ -9,12 +9,20 @@ on:
       - "flake.nix"
       - "flake.lock"
       - "nix/**"
+      - "!nix/docker/README.md"
+      - "!nix/devshell.nix"
+      - "bin/check-tools.sh"
+      - "bin/install-sanitizer-libs.sh"
   pull_request:
     paths:
       - ".github/workflows/build-nix-images.yml"
       - "flake.nix"
       - "flake.lock"
       - "nix/**"
+      - "!nix/docker/README.md"
+      - "!nix/devshell.nix"
+      - "bin/check-tools.sh"
+      - "bin/install-sanitizer-libs.sh"
   workflow_dispatch:
 
 concurrency:

.github/workflows/publish-docs.yml

@@ -41,7 +41,7 @@ env:
 jobs:
   build:
     runs-on: ubuntu-latest
-    container: ghcr.io/xrplf/xrpld/nix-ubuntu:sha-63ffdc3
+    container: ghcr.io/xrplf/xrpld/nix-ubuntu:sha-fe4c8ae
     steps:
       - name: Checkout repository
         uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3

.github/workflows/reusable-build-test-config.yml

@@ -121,6 +121,11 @@ jobs:
         if: ${{ inputs.ccache_enabled && runner.debug == '1' }}
         run: echo "CCACHE_LOGFILE=${{ runner.temp }}/ccache.log" >>"${GITHUB_ENV}"
 
+      - name: Check tools
+        env:
+          CHECK_TOOLS_SKIP_CLONE: "1"
+        run: ./bin/check-tools.sh
+
       - name: Print build environment
         uses: XRPLF/actions/print-build-env@59dec886e4afb05a1724443af08baccbc045b574
 

.github/workflows/reusable-clang-tidy.yml

@@ -36,7 +36,7 @@ jobs:
     needs: [determine-files]
     if: ${{ always() && !cancelled() && (!inputs.check_only_changed || needs.determine-files.outputs.cpp_changed_files != '' || needs.determine-files.outputs.clang_tidy_config_changed == 'true') }}
     runs-on: ["self-hosted", "Linux", "X64", "heavy"]
-    container: "ghcr.io/xrplf/xrpld/nix-debian:sha-63ffdc3"
+    container: "ghcr.io/xrplf/xrpld/nix-debian:sha-fe4c8ae"
     permissions:
       contents: read
       issues: write

.github/workflows/reusable-upload-recipe.yml

@@ -40,7 +40,7 @@ defaults:
 jobs:
   upload:
     runs-on: ubuntu-latest
-    container: ghcr.io/xrplf/xrpld/nix-ubuntu:sha-63ffdc3
+    container: ghcr.io/xrplf/xrpld/nix-ubuntu:sha-fe4c8ae
     steps:
       - name: Checkout repository
         uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3

BUILD.md

@@ -1,26 +1,57 @@
-| :warning: **WARNING** :warning:                                                                                                                                                                                                |
-| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| These instructions assume you have a C++ development environment ready with Git, Python, Conan, CMake, and a C++ compiler. For help setting one up on Linux, macOS, or Windows, [see this guide](./docs/build/environment.md). |
+| :warning: **WARNING** :warning:                                                                                                                                                                                                                                                                                                                                                                                                                                               |
+| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| These instructions assume you have a C++ development environment ready with Git, Python, Conan, CMake, and a C++ compiler. For help setting one up on Linux, macOS, or Windows, [see this guide](./docs/build/environment.md).<br><br>These instructions also assume a basic familiarity with Conan and CMake. If you are unfamiliar with Conan, you can read our [crash course](./docs/build/conan.md) or the official [Getting Started][conan-getting-started] walkthrough. |
 
-> These instructions also assume a basic familiarity with Conan and CMake.
-> If you are unfamiliar with Conan, you can read our
-> [crash course](./docs/build/conan.md) or the official [Getting Started][3]
-> walkthrough.
+## Minimum Requirements
 
-## Branches
+See [System Requirements](https://xrpl.org/system-requirements.html).
 
-For a stable release, choose the `master` branch or one of the [tagged
-releases](https://github.com/XRPLF/rippled/releases).
+Building xrpld generally requires Git, Python, Conan, CMake, and a C++
+compiler.
+
+- [Python](https://www.python.org/downloads/)
+- [Conan](https://conan.io/downloads.html)
+- [CMake](https://cmake.org/download/)
+
+You can verify that the required tools are installed and runnable with:
 
 ```bash
-git checkout master
+./bin/check-tools.sh
 ```
 
-For the latest release candidate, choose the `release` branch.
+`xrpld` is written in the C++23 dialect. The [tested compiler versions][cpp23-support] are:
 
-```bash
-git checkout release
-```
+| Compiler    | Version         |
+| ----------- | --------------- |
+| GCC         | 15.2            |
+| Clang       | 22              |
+| Apple Clang | 17              |
+| MSVC        | 19.44[^windows] |
+
+## Operating Systems
+
+Please see the [environment setup guide](./docs/build/environment.md) for detailed instructions for all platforms.
+
+### Linux
+
+The Ubuntu Linux distribution has received the highest level of quality
+assurance, testing, and support. We also support Red Hat and use Debian
+internally.
+Our Linux CI tooling is distro-independent and uses a Nix-based environment, so it should be possible to build on other Linux distributions as well, although we have not tested them.
+
+### macOS
+
+Many `xrpld` engineers use macOS for development.
+
+### Windows
+
+Windows is used by some engineers for development only.
+
+[^windows]: Windows is not recommended for production use.
+
+## Steps
+
+### Branches
 
 For the latest set of untested features, or to contribute, choose the `develop`
 branch.
@@ -29,55 +60,15 @@ branch.
 git checkout develop
 ```
 
-## Minimum Requirements
+For a release candidate, choose the relevant release branch, e.g.
+`release/3.2.x`.
 
-See [System Requirements](https://xrpl.org/system-requirements.html).
+```bash
+git checkout release/3.2.x
+```
 
-Building xrpld generally requires git, Python, Conan, CMake, and a C++
-compiler. Some guidance on setting up such a [C++ development environment can be
-found here](./docs/build/environment.md).
-
-- [Python 3.11](https://www.python.org/downloads/), or higher
-- [Conan 2.17](https://conan.io/downloads.html)[^1], or higher
-- [CMake 3.22](https://cmake.org/download/), or higher
-
-[^1]:
-    It is possible to build with Conan 1.60+, but the instructions are
-    significantly different, which is why we are not recommending it.
-
-`xrpld` is written in the C++23 dialect and includes the `<concepts>` header.
-The [tested compiler versions][2] are:
-
-| Compiler    | Version   |
-| ----------- | --------- |
-| GCC         | 15        |
-| Clang       | 22        |
-| Apple Clang | 17        |
-| MSVC        | 19.44[^3] |
-
-### Linux
-
-The Ubuntu Linux distribution has received the highest level of quality
-assurance, testing, and support. We also support Red Hat and use Debian
-internally.
-
-Here are [sample instructions for setting up a C++ development environment on
-Linux](./docs/build/environment.md#linux).
-
-### Mac
-
-Many xrpld engineers use macOS for development.
-
-Here are [sample instructions for setting up a C++ development environment on
-macOS](./docs/build/environment.md#macos).
-
-### Windows
-
-Windows is used by some engineers for development only.
-
-[^3]: Windows is not recommended for production use.
-
-## Steps
+For a stable release, choose one of the [tagged
+releases](https://github.com/XRPLF/rippled/releases).
 
 ### Set Up Conan
 
@@ -86,18 +77,11 @@ Conan, CMake, and a C++ compiler, you may need to set up your Conan profile.
 
 These instructions assume a basic familiarity with Conan and CMake. If you are
 unfamiliar with Conan, then please read [this crash course](./docs/build/conan.md) or the official
-[Getting Started][3] walkthrough.
+[Getting Started][conan-getting-started] walkthrough.
 
-#### Conan lockfile
+#### Profiles
 
-To achieve reproducible dependencies, we use a [Conan lockfile](https://docs.conan.io/2/tutorial/versioning/lockfiles.html),
-which has to be updated every time dependencies change.
-
-Please see the [instructions on how to regenerate the lockfile](conan/lockfile/README.md).
-
-#### Default profile
-
-We recommend that you import the provided `conan/profiles/default` profile:
+We recommend that you install our Conan profiles:
 
 ```bash
 conan config install conan/profiles/ -tf $(conan config home)/profiles/
@@ -109,222 +93,15 @@ You can check your Conan profile by running:
 conan profile show
 ```
 
-#### Custom profile
+If the default profile is not suitable for your environment, you can create a custom profile and pass it to Conan.
+More information on customizing Conan can be found in the [Advanced Conan configuration](./docs/build/advanced_conan.md).
 
-If the default profile does not work for you and you do not yet have a Conan
-profile, you can create one by running:
+#### Add xrplf remote
+
+Run the following command to add the `xrplf` remote, which hosts some of our dependencies:
 
 ```bash
-conan profile detect
-```
-
-You may need to make changes to the profile to suit your environment. You can
-refer to the provided `conan/profiles/default` profile for inspiration, and you
-may also need to apply the required [tweaks](#conan-profile-tweaks) to this
-default profile.
-
-### Patched recipes
-
-Occasionally, we need patched recipes or recipes not present in Conan Center.
-We maintain a fork of the Conan Center Index
-[here](https://github.com/XRPLF/conan-center-index/) containing the modified and newly added recipes.
-
-To ensure our patched recipes are used, you must add our Conan remote at a
-higher index than the default Conan Center remote, so it is consulted first. You
-can do this by running:
-
-```bash
-conan remote add --index 0 xrplf https://conan.ripplex.io
-```
-
-Alternatively, you can pull our recipes from the repository and export them locally:
-
-```bash
-# Define which recipes to export.
-recipes=('abseil' 'ed25519' 'mpt-crypto' 'openssl' 'secp256k1' 'snappy' 'soci' 'wasm-xrplf' 'wasmi')
-
-# Selectively check out the recipes from our CCI fork.
-cd external
-mkdir -p conan-center-index
-cd conan-center-index
-git init
-git remote add origin git@github.com:XRPLF/conan-center-index.git
-git sparse-checkout init
-for recipe in "${recipes[@]}"; do
-    echo "Checking out recipe '${recipe}'..."
-    git sparse-checkout add recipes/${recipe}
-done
-git fetch origin master
-git checkout master
-
-./export_all.sh
-cd ../../
-```
-
-In the case we switch to a newer version of a dependency that still requires a
-patch or add a new dependency, it will be necessary for you to pull in the changes and re-export the
-updated dependencies with the newer version. However, if we switch to a newer
-version that no longer requires a patch, no action is required on your part, as
-the new recipe will be automatically pulled from the official Conan Center.
-
-> [!NOTE]
-> You might need to add `--lockfile=""` to your `conan install` command
-> to avoid automatic use of the existing `conan.lock` file when you run
-> `conan export` manually on your machine
->
-> This is not recommended though, as you might end up using different revisions of recipes.
-
-### Conan profile tweaks
-
-#### Missing compiler version
-
-If you see an error similar to the following after running `conan profile show`:
-
-```text
-ERROR: Invalid setting '17' is not a valid 'settings.compiler.version' value.
-Possible values are ['5.0', '5.1', '6.0', '6.1', '7.0', '7.3', '8.0', '8.1',
-'9.0', '9.1', '10.0', '11.0', '12.0', '13', '13.0', '13.1', '14', '14.0', '15',
-'15.0', '16', '16.0']
-Read "http://docs.conan.io/2/knowledge/faq.html#error-invalid-setting"
-```
-
-you need to add your compiler to the list of compiler versions in
-`$(conan config home)/settings_user.yml`, by adding the required version number(s)
-to the `version` array specific for your compiler. For example:
-
-```yaml
-compiler:
-  apple-clang:
-    version: ["17.0"]
-```
-
-#### Multiple compilers
-
-If you have multiple compilers installed, make sure to select the one to use in
-your default Conan configuration **before** running `conan profile detect`, by
-setting the `CC` and `CXX` environment variables.
-
-For example, if you are running MacOS and have [homebrew
-LLVM@18](https://formulae.brew.sh/formula/llvm@18), and want to use it as a
-compiler in the new Conan profile:
-
-```bash
-export CC=$(brew --prefix llvm@18)/bin/clang
-export CXX=$(brew --prefix llvm@18)/bin/clang++
-conan profile detect
-```
-
-You should also explicitly set the path to the compiler in the profile file,
-which helps to avoid errors when `CC` and/or `CXX` are set and disagree with the
-selected Conan profile. For example:
-
-```text
-[conf]
-tools.build:compiler_executables={'c':'/usr/bin/gcc','cpp':'/usr/bin/g++'}
-```
-
-#### Multiple profiles
-
-You can manage multiple Conan profiles in the directory
-`$(conan config home)/profiles`, for example renaming `default` to a different
-name and then creating a new `default` profile for a different compiler.
-
-#### Select language
-
-The default profile created by Conan will typically select different C++ dialect
-than C++23 used by this project. You should set `23` in the profile line
-starting with `compiler.cppstd=`. For example:
-
-```bash
-sed -i.bak -e 's|^compiler\.cppstd=.*$|compiler.cppstd=23|' $(conan config home)/profiles/default
-```
-
-#### Select standard library in Linux
-
-**Linux** developers will commonly have a default Conan [profile][] that
-compiles with GCC and links with libstdc++. If you are linking with libstdc++
-(see profile setting `compiler.libcxx`), then you will need to choose the
-`libstdc++11` ABI:
-
-```bash
-sed -i.bak -e 's|^compiler\.libcxx=.*$|compiler.libcxx=libstdc++11|' $(conan config home)/profiles/default
-```
-
-#### Select architecture and runtime in Windows
-
-**Windows** developers may need to use the x64 native build tools. An easy way
-to do that is to run the shortcut "x64 Native Tools Command Prompt" for the
-version of Visual Studio that you have installed.
-
-Windows developers must also build `xrpld` and its dependencies for the x64
-architecture:
-
-```bash
-sed -i.bak -e 's|^arch=.*$|arch=x86_64|' $(conan config home)/profiles/default
-```
-
-**Windows** developers also must select static runtime:
-
-```bash
-sed -i.bak -e 's|^compiler\.runtime=.*$|compiler.runtime=static|' $(conan config home)/profiles/default
-```
-
-#### Clang workaround for grpc
-
-If your compiler is clang, version 19 or later, or apple-clang, version 17 or
-later, you may encounter a compilation error while building the `grpc`
-dependency:
-
-```text
-In file included from .../lib/promise/try_seq.h:26:
-.../lib/promise/detail/basic_seq.h:499:38: error: a template argument list is expected after a name prefixed by the template keyword [-Wmissing-template-arg-list-after-template-kw]
-  499 |                     Traits::template CallSeqFactory(f_, *cur_, std::move(arg)));
-      |                                      ^
-```
-
-The workaround for this error is to add two lines to profile:
-
-```text
-[conf]
-tools.build:cxxflags=['-Wno-missing-template-arg-list-after-template-kw']
-```
-
-#### Workaround for gcc 12
-
-If your compiler is gcc, version 12, and you have enabled `werr` option, you may
-encounter a compilation error such as:
-
-```text
-/usr/include/c++/12/bits/char_traits.h:435:56: error: 'void* __builtin_memcpy(void*, const void*, long unsigned int)' accessing 9223372036854775810 or more bytes at offsets [2, 9223372036854775807] and 1 may overlap up to 9223372036854775813 bytes at offset -3 [-Werror=restrict]
-  435 |         return static_cast<char_type*>(__builtin_memcpy(__s1, __s2, __n));
-      |                                        ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
-cc1plus: all warnings being treated as errors
-```
-
-The workaround for this error is to add two lines to your profile:
-
-```text
-[conf]
-tools.build:cxxflags=['-Wno-restrict']
-```
-
-#### Workaround for clang 16
-
-If your compiler is clang, version 16, you may encounter compilation error such
-as:
-
-```text
-In file included from .../boost/beast/websocket/stream.hpp:2857:
-.../boost/beast/websocket/impl/read.hpp:695:17: error: call to 'async_teardown' is ambiguous
-                async_teardown(impl.role, impl.stream(),
-                ^~~~~~~~~~~~~~
-```
-
-The workaround for this error is to add two lines to your profile:
-
-```text
-[conf]
-tools.build:cxxflags=['-DBOOST_ASIO_DISABLE_CONCEPTS']
+conan remote add --index 0 --force xrplf https://conan.ripplex.io
 ```
 
 ### Set Up Ccache
@@ -333,14 +110,7 @@ To speed up repeated compilations, we recommend that you install
 [ccache](https://ccache.dev), a tool that wraps your compiler so that it can
 cache build objects locally.
 
-#### Linux
-
-You can install it using the package manager, e.g. `sudo apt install ccache`
-(Ubuntu) or `sudo dnf install ccache` (RHEL).
-
-#### macOS
-
-You can install it using Homebrew, i.e. `brew install ccache`.
+On Linux and macOS, `ccache` is included in the [Nix development shell](./docs/build/nix.md).
 
 #### Windows
 
@@ -549,7 +319,7 @@ See [Sanitizers docs](./docs/build/sanitizers.md) for more details.
 
 | Option     | Default Value | Description                                                    |
 | ---------- | ------------- | -------------------------------------------------------------- |
-| `assert`   | OFF           | Enable assertions.                                             |
+| `assert`   | OFF           | Force enabling assertions.                                     |
 | `coverage` | OFF           | Prepare the coverage report.                                   |
 | `tests`    | OFF           | Build tests.                                                   |
 | `unity`    | OFF           | Configure a unity build.                                       |
@@ -557,7 +327,7 @@ See [Sanitizers docs](./docs/build/sanitizers.md) for more details.
 | `werr`     | OFF           | Treat compilation warnings as errors                           |
 | `wextra`   | OFF           | Enable additional compilation warnings                         |
 
-[Unity builds][5] may be faster for the first build (at the cost of much more
+[Unity builds][unity-build] may be faster for the first build (at the cost of much more
 memory) since they concatenate sources into fewer translation units. Non-unity
 builds may be faster for incremental builds, and can be helpful for detecting
 `#include` omissions.
@@ -583,14 +353,14 @@ After any updates or changes to dependencies, you may need to do the following:
    conan remove '*'
    ```
 
-3. Re-run [conan export](#patched-recipes) if needed.
-4. [Regenerate lockfile](#conan-lockfile).
+3. Re-run [conan export](./docs/build/advanced_conan.md#patched-recipes) if needed.
+4. [Regenerate lockfile](./docs/build/advanced_conan.md#conan-lockfile).
 5. Re-run [conan install](#build-and-test).
 
 #### ERROR: Package not resolved
 
 If you're seeing an error like `ERROR: Package 'snappy/1.1.10' not resolved: Unable to find 'snappy/1.1.10#968fef506ff261592ec30c574d4a7809%1756234314.246' in remotes.`,
-please add `xrplf` remote or re-run `conan export` for [patched recipes](#patched-recipes).
+please [add `xrplf` remote](#add-xrplf-remote) or re-run `conan export` for [patched recipes](./docs/build/advanced_conan.md#patched-recipes).
 
 ### `protobuf/port_def.inc` file not found
 
@@ -610,28 +380,9 @@ For example, if you want to build Debug:
 1. For conan install, pass `--settings build_type=Debug`
 2. For cmake, pass `-DCMAKE_BUILD_TYPE=Debug`
 
-## Add a Dependency
-
-If you want to experiment with a new package, follow these steps:
-
-1. Search for the package on [Conan Center](https://conan.io/center/).
-2. Modify [`conanfile.py`](./conanfile.py):
-   - Add a version of the package to the `requires` property.
-   - Change any default options for the package by adding them to the
-     `default_options` property (with syntax `'$package:$option': $value`).
-3. Modify [`CMakeLists.txt`](./CMakeLists.txt):
-   - Add a call to `find_package($package REQUIRED)`.
-   - Link a library from the package to the target `xrpl_libs`
-     (search for the existing call to `target_link_libraries(xrpl_libs INTERFACE ...)`).
-4. Start coding! Don't forget to include whatever headers you need from the package.
-
-[1]: https://github.com/conan-io/conan-center-index/issues/13168
-[2]: https://en.cppreference.com/w/cpp/compiler_support/20
-[3]: https://docs.conan.io/en/latest/getting_started.html
-[5]: https://en.wikipedia.org/wiki/Unity_build
-[6]: https://github.com/boostorg/beast/issues/2648
-[7]: https://github.com/boostorg/beast/issues/2661
+[cpp23-support]: https://en.cppreference.com/w/cpp/compiler_support/23
+[conan-getting-started]: https://docs.conan.io/en/latest/getting_started.html
+[unity-build]: https://en.wikipedia.org/wiki/Unity_build
 [gcovr]: https://gcovr.com/en/stable/getting-started.html
 [python-pip]: https://packaging.python.org/en/latest/guides/installing-using-pip-and-virtual-environments/
 [build_type]: https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html
-[profile]: https://docs.conan.io/en/latest/reference/profiles.html

CONTRIBUTING.md

@@ -14,9 +14,9 @@ The following branches exist in the main project repository:
 
 - `develop`: The latest set of unreleased features, and the most common
   starting point for contributions.
-- `release`: The latest beta release or release candidate.
-- `master`: The latest stable release.
-- `gh-pages`: The documentation for this project, built by Doxygen.
+- `release/*` (e.g. `release/3.2.x`): Release branches, one per release line,
+  holding the latest release candidate, or stable release for that line.
+  Stable releases are published as [tagged releases](https://github.com/XRPLF/rippled/releases).
 
 The tip of each branch must be signed. In order for GitHub to sign a
 squashed commit that it builds from your pull request, GitHub must know
@@ -130,11 +130,9 @@ tl;dr
 ## Pull requests
 
 In general, pull requests use `develop` as the base branch.
-The exceptions are
 
-- Fixes and improvements to a release candidate use `release` as the
-  base.
-- Hotfixes use `master` as the base.
+The exceptions are fixes, improvements, and hotfixes for an existing release,
+which use that release's branch (e.g. `release/3.2.x`) as the base.
 
 If your changes are not quite ready, but you want to make it easily available
 for preliminary examination or review, you can create a "Draft" pull request.
@@ -216,7 +214,7 @@ coherent rather than a set of _thou shalt not_ commandments.
 
 ## Formatting
 
-All code must conform to `clang-format` version 21,
+All code must conform to `clang-format` version 22,
 according to the settings in [`.clang-format`](./.clang-format),
 unless the result would be unreasonably difficult to read or maintain.
 To demarcate lines that should be left as-is, surround them with comments like
@@ -261,7 +259,7 @@ This ensures that configuration changes don't introduce new warnings across the
 
 ### Installing clang-tidy
 
-See the [environment setup guide](./docs/build/environment.md#clang-tidy) for platform-specific installation instructions.
+See the [environment setup guide](./docs/build/environment.md#clang-tidy) for how to get clang-tidy.
 
 ### Running clang-tidy locally
 

bin/check-tools.sh

@@ -0,0 +1,158 @@
+#!/usr/bin/env bash
+#
+# check-tools.sh — verify the xrpld development tooling is present and runnable.
+#
+# Works on Linux, macOS, and Windows (Git Bash / MSYS). For every expected tool
+# it runs a version probe, collecting anything that is missing or fails to run,
+# and prints a summary at the end (exiting non-zero if anything is missing).
+#
+# The tool set is platform-aware:
+#   - Linux:   the full Nix CI environment (see nix/packages.nix, nix/ci-env.nix),
+#              with GCC, Clang and the sanitizer/coverage tooling. This script is
+#              run during the Nix Docker image build (nix/docker/Dockerfile), so
+#              the Linux list is kept in sync with that environment.
+#   - macOS:   the same tooling, minus GCC/g++/gcov/mold
+#   - Windows: the core build tools only (CMake, Conan, Git, Python).
+#              MSVC is expected to be provided separately and is not checked here.
+#
+# Some tools (clang-format, doxygen, gcovr, gh, git-cliff, gpg, pre-commit,
+# run-clang-tidy) are present in our Linux CI images and in local development
+# setups, but not in the macOS CI environment. They are checked everywhere
+# except when running in CI on macOS.
+#
+# Environment variables:
+#   CI                      if set, skip the tools above when on macOS.
+#   CHECK_TOOLS_SKIP_CLONE  if set, skip the git-over-HTTPS connectivity check.
+
+set -uo pipefail
+
+missing=()
+checked=0
+
+# check <name> [probe-command...]
+# Runs the probe (default: "<name> --version") quietly. Records <name> as
+# missing if the command is not found or exits non-zero.
+check() {
+    local name="$1"
+    shift
+    local -a probe=("$@")
+    if [ "${#probe[@]}" -eq 0 ]; then
+        probe=("${name}" --version)
+    fi
+
+    echo "Checking ${name}..."
+    checked=$((checked + 1))
+    if "${probe[@]}" | head -n 1; then
+        printf '  [ ok ] %s\n' "${name}"
+    else
+        printf '  [MISS] %s\n' "${name}"
+        missing+=("${name}")
+    fi
+}
+
+case "$(uname -s)" in
+    Linux*) os=linux ;;
+    Darwin*) os=macos ;;
+    MINGW* | MSYS* | CYGWIN*) os=windows ;;
+    *)
+        echo "Unknown OS: $(uname -s)" >&2
+        exit 1
+        ;;
+esac
+
+echo "Detected OS: ${os} ($(uname -s) $(uname -m))"
+echo
+echo "Core build tools:"
+check cmake
+check conan
+check git
+if [ "${os}" = "windows" ]; then
+    check python python --version
+else
+    check python3
+fi
+
+# The full development toolchain. Available from Nix on Linux and macOS; on
+# Windows these are typically not installed, so they are skipped.
+if [ "${os}" = "linux" ] || [ "${os}" = "macos" ]; then
+    echo
+    echo "Development tooling:"
+    check ccache
+    check clang
+    check clang++
+    check ClangBuildAnalyzer
+    check curl
+    check file
+    check less
+    check make
+    check netstat which netstat
+    check ninja
+    check perl
+    check pkg-config
+    check vim
+
+    # These tools are present in our Linux CI images and in local development
+    # setups, but not in the macOS CI environment. So check them everywhere
+    # except when running in CI on macOS.
+    if [ "${os}" = "linux" ] || [ -z "${CI:-}" ]; then
+        check clang-format
+        check doxygen
+        check gcovr
+        check gh
+        check git-cliff
+        check gpg
+        # pre-commit, or its alternative implementation prek
+        check pre-commit sh -c 'pre-commit --version || prek --version'
+        check run-clang-tidy run-clang-tidy --help
+    fi
+fi
+
+# GCC is the default compiler on Linux. macOS uses the system Apple Clang
+# instead, so GCC/g++/gcov are not expected there.
+if [ "${os}" = "linux" ]; then
+    echo
+    echo "GCC toolchain:"
+    check gcc
+    check g++
+    check gcov
+
+    echo
+    echo "Mold:"
+    check mold
+fi
+
+if [ "${os}" = "windows" ]; then
+    echo
+    echo "Note: on Windows the C++ compiler is MSVC, which is provided"
+    echo "      separately (e.g. via Visual Studio) and is not checked here."
+fi
+
+# A simple test to verify that git can clone a repository over HTTPS
+# (i.e. the CA bundle is wired up). Clone to a temp dir and clean up.
+if [ -n "${CHECK_TOOLS_SKIP_CLONE:-}" ]; then
+    echo
+    echo "Skipping git-over-HTTPS check (CHECK_TOOLS_SKIP_CLONE is set)."
+else
+    echo
+    echo "Connectivity check:"
+    checked=$((checked + 1))
+    tmp_clone="$(mktemp -d)"
+    if git clone --depth 1 https://github.com/XRPLF/actions.git "${tmp_clone}/actions" >/dev/null 2>&1; then
+        printf '  [ ok ] git clone over HTTPS\n'
+    else
+        printf '  [MISS] git clone over HTTPS\n'
+        missing+=("git-https-clone")
+    fi
+    rm -rf "${tmp_clone}"
+fi
+
+echo
+if [ "${#missing[@]}" -eq 0 ]; then
+    echo "All ${checked} checked tools are present and runnable."
+else
+    echo "Missing or non-functional tools (${#missing[@]} of ${checked}):" >&2
+    for tool in "${missing[@]}"; do
+        echo "  - ${tool}" >&2
+    done
+    exit 1
+fi

cspell.config.yaml

@@ -109,6 +109,7 @@ words:
   - enabled
   - enablerepo
   - endmacro
+  - envrc
   - exceptioned
   - EXPECT_STREQ
   - Falco

docs/build/advanced_conan.md

@@ -0,0 +1,193 @@
+# Advanced Conan configuration
+
+This document provides advanced instructions for setting up and configuring Conan for `xrpld` development: custom profiles, the lockfile, patched recipes, and profile tweaks.
+
+## Custom profile
+
+If the default profile does not work for you and you do not yet have a Conan
+profile, you can create one by running:
+
+```bash
+conan profile detect
+```
+
+You may need to make changes to the profile to suit your environment. You can
+refer to the provided `conan/profiles/default` profile for inspiration, and you
+may also need to apply the required [tweaks](#conan-profile-tweaks) to this
+default profile.
+
+## Conan lockfile
+
+To achieve reproducible dependencies, we use a [Conan lockfile](https://docs.conan.io/2/tutorial/versioning/lockfiles.html),
+which has to be updated every time dependencies change.
+
+Please see the [instructions on how to regenerate the lockfile](../../conan/lockfile/README.md).
+
+## Patched recipes
+
+Occasionally, we need patched recipes or recipes not present in Conan Center.
+We maintain a fork of the Conan Center Index
+[here](https://github.com/XRPLF/conan-center-index/) containing the modified and newly added recipes.
+
+To ensure our patched recipes are used, you must add our Conan remote at a
+higher index than the default Conan Center remote, so it is consulted first. You
+can do this by running:
+
+```bash
+conan remote add --index 0 --force xrplf https://conan.ripplex.io
+```
+
+Alternatively, you can pull our recipes from the repository and export them locally:
+
+```bash
+# Define which recipes to export.
+recipes=('abseil' 'ed25519' 'mpt-crypto' 'openssl' 'secp256k1' 'snappy' 'soci' 'wasm-xrplf' 'wasmi')
+
+# Selectively check out the recipes from our CCI fork.
+cd external
+mkdir -p conan-center-index
+cd conan-center-index
+git init
+git remote add origin git@github.com:XRPLF/conan-center-index.git
+git sparse-checkout init
+for recipe in "${recipes[@]}"; do
+    echo "Checking out recipe '${recipe}'..."
+    git sparse-checkout add recipes/${recipe}
+done
+git fetch origin master
+git checkout master
+
+./export_all.sh
+cd ../../
+```
+
+In the case we switch to a newer version of a dependency that still requires a
+patch or add a new dependency, it will be necessary for you to pull in the changes and re-export the
+updated dependencies with the newer version. However, if we switch to a newer
+version that no longer requires a patch, no action is required on your part, as
+the new recipe will be automatically pulled from the official Conan Center.
+
+> [!NOTE]
+> You might need to add `--lockfile=""` to your `conan install` command
+> to avoid automatic use of the existing `conan.lock` file when you run
+> `conan export` manually on your machine
+>
+> This is not recommended though, as you might end up using different revisions of recipes.
+
+## Conan profile tweaks
+
+### Missing compiler version
+
+If you see an error similar to the following after running `conan profile show`:
+
+```text
+ERROR: Invalid setting '17' is not a valid 'settings.compiler.version' value.
+Possible values are ['5.0', '5.1', '6.0', '6.1', '7.0', '7.3', '8.0', '8.1',
+'9.0', '9.1', '10.0', '11.0', '12.0', '13', '13.0', '13.1', '14', '14.0', '15',
+'15.0', '16', '16.0']
+Read "http://docs.conan.io/2/knowledge/faq.html#error-invalid-setting"
+```
+
+you need to create `$(conan config home)/settings_user.yml` file if it doesn't exist and add the required version number(s)
+to the `version` array specific for your compiler. For example:
+
+```yaml
+compiler:
+  apple-clang:
+    version: ["17.0"]
+```
+
+### Multiple compilers
+
+If you have multiple compilers installed, make sure to select the one to use in
+your default Conan configuration **before** running `conan profile detect`, by
+setting the `CC` and `CXX` environment variables.
+
+For example, if you are running MacOS and have [homebrew
+LLVM@18](https://formulae.brew.sh/formula/llvm@18), and want to use it as a
+compiler in the new Conan profile:
+
+```bash
+export CC=$(brew --prefix llvm@18)/bin/clang
+export CXX=$(brew --prefix llvm@18)/bin/clang++
+conan profile detect
+```
+
+You should also explicitly set the path to the compiler in the profile file,
+which helps to avoid errors when `CC` and/or `CXX` are set and disagree with the
+selected Conan profile. For example:
+
+```text
+[conf]
+tools.build:compiler_executables={'c':'/usr/bin/gcc','cpp':'/usr/bin/g++'}
+```
+
+### Multiple profiles
+
+You can manage multiple Conan profiles in the directory
+`$(conan config home)/profiles`, for example renaming `default` to a different
+name and then creating a new `default` profile for a different compiler.
+
+### Select language
+
+The default profile created by Conan will typically select different C++ dialect
+than C++23 used by this project. You should set `23` in the profile line
+starting with `compiler.cppstd=`. For example:
+
+```bash
+sed -i.bak -e 's|^compiler\.cppstd=.*$|compiler.cppstd=23|' $(conan config home)/profiles/default
+```
+
+### Select standard library in Linux
+
+**Linux** developers will commonly have a default Conan [profile][] that
+compiles with GCC and links with libstdc++. If you are linking with libstdc++
+(see profile setting `compiler.libcxx`), then you will need to choose the
+`libstdc++11` ABI:
+
+```bash
+sed -i.bak -e 's|^compiler\.libcxx=.*$|compiler.libcxx=libstdc++11|' $(conan config home)/profiles/default
+```
+
+### Select architecture and runtime in Windows
+
+**Windows** developers may need to use the x64 native build tools. An easy way
+to do that is to run the shortcut "x64 Native Tools Command Prompt" for the
+version of Visual Studio that you have installed.
+
+Windows developers must also build `xrpld` and its dependencies for the x64
+architecture:
+
+```bash
+sed -i.bak -e 's|^arch=.*$|arch=x86_64|' $(conan config home)/profiles/default
+```
+
+**Windows** developers also must select static runtime:
+
+```bash
+sed -i.bak -e 's|^compiler\.runtime=.*$|compiler.runtime=static|' $(conan config home)/profiles/default
+```
+
+## Add a Dependency
+
+If you want to experiment with a new package, follow these steps:
+
+1. Search for the package on [Conan Center](https://conan.io/center/).
+2. Modify [`conanfile.py`](../../conanfile.py):
+   - Add a version of the package to the `requires` property.
+   - Change any default options for the package by adding them to the
+     `default_options` property (with syntax `'$package:$option': $value`).
+3. Regenerate the [Conan lockfile](../../conan/lockfile/README.md) so the new
+   dependency is captured:
+
+   ```bash
+   ./conan/lockfile/regenerate.sh
+   ```
+
+4. Modify [`CMakeLists.txt`](../../CMakeLists.txt):
+   - Add a call to `find_package($package REQUIRED)`.
+   - Link a library from the package to the target `xrpl_libs`
+     (search for the existing call to `target_link_libraries(xrpl_libs INTERFACE ...)`).
+5. Start coding! Don't forget to include whatever headers you need from the package.
+
+[profile]: https://docs.conan.io/2/reference/config_files/profiles.html

docs/build/conan.md

@@ -115,7 +115,7 @@ By default, Conan will use the profile named "default".
 [find_package]: https://cmake.org/cmake/help/latest/command/find_package.html
 [pcf]: https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#package-configuration-file
 [prefix_path]: https://cmake.org/cmake/help/latest/variable/CMAKE_PREFIX_PATH.html
-[profile]: https://docs.conan.io/en/latest/reference/profiles.html
+[profile]: https://docs.conan.io/2/reference/config_files/profiles.html
 [pvf]: https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#package-version-file
 [runtime]: https://cmake.org/cmake/help/latest/variable/CMAKE_MSVC_RUNTIME_LIBRARY.html
 [search]: https://cmake.org/cmake/help/latest/command/find_package.html#search-procedure

docs/build/environment.md

@@ -1,69 +1,73 @@
 Our [build instructions][BUILD.md] assume you have a C++ development
 environment complete with Git, Python, Conan, CMake, and a C++ compiler.
-This document exists to help readers set one up on any of the Big Three
-platforms: Linux, macOS, or Windows.
-
-As an alternative to system packages, the Nix development shell can be used to provide a development environment. See [using nix development shell](./nix.md) for more details.
+This document explains how to set one up.
 
 [BUILD.md]: ../../BUILD.md
 
-## Linux
+## Tested compiler versions
 
-Package ecosystems vary across Linux distributions,
-so there is no one set of instructions that will work for every Linux user.
-The instructions below are written for Debian 12 (Bookworm).
+`xrpld` is built in the **C++23** dialect by default.
+Make sure your toolchain is recent enough — the compiler versions currently tested in CI are:
 
-```
-export GCC_RELEASE=12
-sudo apt update
-sudo apt install --yes gcc-${GCC_RELEASE} g++-${GCC_RELEASE} python3-pip \
-  python-is-python3 python3-venv python3-dev curl wget ca-certificates \
-  git build-essential cmake ninja-build libc6-dev
-sudo pip install --break-system-packages conan
+| Compiler    | Version |
+| ----------- | ------- |
+| GCC         | 15.2    |
+| Clang       | 22      |
+| Apple Clang | 17      |
+| MSVC        | 19.44   |
 
-sudo update-alternatives --install /usr/bin/cc cc /usr/bin/gcc-${GCC_RELEASE} 999
-sudo update-alternatives --install \
-  /usr/bin/gcc gcc /usr/bin/gcc-${GCC_RELEASE} 100 \
-  --slave /usr/bin/g++ g++ /usr/bin/g++-${GCC_RELEASE} \
-  --slave /usr/bin/gcc-ar gcc-ar /usr/bin/gcc-ar-${GCC_RELEASE} \
-  --slave /usr/bin/gcc-nm gcc-nm /usr/bin/gcc-nm-${GCC_RELEASE} \
-  --slave /usr/bin/gcc-ranlib gcc-ranlib /usr/bin/gcc-ranlib-${GCC_RELEASE} \
-  --slave /usr/bin/gcov gcov /usr/bin/gcov-${GCC_RELEASE} \
-  --slave /usr/bin/gcov-tool gcov-tool /usr/bin/gcov-tool-${GCC_RELEASE} \
-  --slave /usr/bin/gcov-dump gcov-dump /usr/bin/gcov-dump-${GCC_RELEASE} \
-  --slave /usr/bin/lto-dump lto-dump /usr/bin/lto-dump-${GCC_RELEASE}
-sudo update-alternatives --auto cc
-sudo update-alternatives --auto gcc
+LLVM tools (`clang-tidy` and `clang-format`) are also pinned to version 22.
+
+Older compilers may fail to build the latest `develop` code: the codebase now
+relies on C++23 features and has been adjusted for `clang-tidy`.
+If the latest code doesn't build for you, update your build toolchain first.
+
+## Linux and macOS
+
+The **recommended way** to get a development environment on Linux and macOS is
+the Nix development shell. It provides the exact tooling used in CI — `git`,
+`python`, `conan`, `cmake`, `clang-tidy`, `clang-format`, and everything else —
+with a single command and without installing anything system-wide:
+
+```bash
+nix --experimental-features 'nix-command flakes' develop
 ```
 
-If you use different Linux distribution, hope the instruction above can guide
-you in the right direction. We try to maintain compatibility with all recent
-compiler releases, so if you use a rolling distribution like e.g. Arch or CentOS
-then there is a chance that everything will "just work".
+On **Linux**, Nix also provides the compiler (GCC). On **macOS**, the shell uses
+your **system-wide Apple Clang** as the compiler, so you still need to manage
+its version (see below).
 
-## macOS
+See [Using the Nix development shell](./nix.md) for installation and usage
+details, including how to select a different compiler.
 
-Open a Terminal and enter the below command to bring up a dialog to install
-the command line developer tools.
-Once it is finished, this command should return a version greater than the
-minimum required (see [BUILD.md][]).
+> [!NOTE]
+> Using Nix is not mandatory. Any custom environment (Homebrew packages or
+> anything else) will continue to work, but then it is up to you to keep it in
+> sync with the environment used in CI. Nix unifies the development environment
+> for everyone and synchronizes updates, which is why we recommend it.
 
-```
+### macOS: managing the Apple Clang version
+
+Because the Nix shell uses the system-wide Apple Clang on macOS, the compiler
+version is whatever your installed Xcode (or Command Line Tools) provides. The
+following command should return a version greater than or equal to the
+[minimum required](#tested-compiler-versions):
+
+```bash
 clang --version
 ```
 
-### Install Xcode Specific Version (Optional)
-
-If you develop other applications using XCode you might be consistently updating to the newest version of Apple Clang.
-This will likely cause issues building xrpld. You may want to install a specific version of Xcode:
+If you develop other applications using Xcode, you might be consistently
+updating to the newest version of Apple Clang, which will likely cause issues
+building xrpld. You may want to install and pin a specific version of Xcode:
 
 1. **Download Xcode**
    - Visit [Apple Developer Downloads](https://developer.apple.com/download/more/)
    - Sign in with your Apple Developer account
-   - Search for an Xcode version that includes **Apple Clang (Expected Version)**
+   - Search for an Xcode version that includes the expected Apple Clang version
    - Download the `.xip` file
 
-2. **Install and Configure Xcode**
+2. **Install and configure Xcode**
 
    ```bash
    # Extract the .xip file and rename for version management
@@ -79,62 +83,28 @@ This will likely cause issues building xrpld. You may want to install a specific
    export DEVELOPER_DIR=/Applications/Xcode_16.2.app/Contents/Developer
    ```
 
-The command line developer tools should include Git too:
+## Windows
 
-```
-git --version
-```
+Nix is not available on Windows, so the required tools have to be installed
+manually:
 
-Install [Homebrew][],
-use it to install [pyenv][],
-use it to install Python,
-and use it to install Conan:
+- [Visual Studio 2022](https://visualstudio.microsoft.com/) with the
+  **"Desktop development with C++"** workload — this provides MSVC and the
+  "x64 Native Tools Command Prompt".
+- [Git for Windows](https://git-scm.com/download/win)
+- [Python 3.11](https://www.python.org/downloads/), or higher
+- [Conan 2.17](https://conan.io/downloads.html), or higher
+- [CMake 3.22](https://cmake.org/download/), or higher
 
-[Homebrew]: https://brew.sh/
-[pyenv]: https://github.com/pyenv/pyenv
-
-```
-/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
-brew update
-brew install xz
-brew install pyenv
-pyenv install 3.11
-pyenv global 3.11
-eval "$(pyenv init -)"
-pip install 'conan'
-```
-
-Install CMake with Homebrew too:
-
-```
-brew install cmake
-```
+> [!NOTE]
+> Windows is used for development only and is not recommended for production.
 
 ## Clang-tidy
 
-Clang-tidy is required to run static analysis checks locally (see [CONTRIBUTING.md](../../CONTRIBUTING.md)).
-It is not required to build the project. Currently this project uses clang-tidy version 21.
+`clang-tidy` is required to run static analysis checks locally (see
+[CONTRIBUTING.md](../../CONTRIBUTING.md)). It is not required to build the
+project. This project currently uses `clang-tidy` version 22.
 
-### Linux
-
-LLVM 21 is not available in the default Debian 12 (Bookworm) repositories.
-Install it using the official LLVM apt installer:
-
-```
-wget https://apt.llvm.org/llvm.sh
-chmod +x llvm.sh
-sudo ./llvm.sh 21
-sudo apt install --yes clang-tidy-21
-```
-
-Then use `run-clang-tidy-21` when running clang-tidy locally.
-
-### macOS
-
-Install LLVM 21 via Homebrew:
-
-```
-brew install llvm@21
-```
-
-Then use `run-clang-tidy` from the LLVM 21 Homebrew prefix when running clang-tidy locally.
+On Linux and macOS, the [Nix development shell](./nix.md) provides `clang-tidy`
+22 out of the box — run it via `run-clang-tidy`. No separate installation is
+needed.

docs/build/nix.md

@@ -2,9 +2,12 @@
 
 This guide explains how to use Nix to set up a reproducible development environment for xrpld. Using Nix eliminates the need to manually install utilities and ensures consistent tooling across different machines.
 
+**The Nix development shell is the recommended way to develop xrpld.** It unifies the development environment for everyone and synchronizes updates: the same tooling and compiler versions are used both here and in CI. Any custom environment (Homebrew packages or anything else) will continue to work, but then it is up to you to keep it in sync with the environment used in CI.
+
 ## Benefits of Using Nix
 
 - **Reproducible environment**: Everyone gets the same versions of tools and compilers
+- **Matches CI**: The Linux CI runs in Docker images built from this exact Nix environment
 - **No system pollution**: Dependencies are isolated and don't affect your system packages
 - **Multiple compiler versions**: Easily switch between different GCC and Clang versions
 - **Quick setup**: Get started with a single command
@@ -28,11 +31,22 @@ This will:
 
 - Download and set up all required development tools (CMake, Ninja, Conan, etc.)
 - Configure the appropriate compiler for your platform:
-  - **macOS**: Apple Clang (default system compiler)
-  - **Linux**: GCC 15
+  - **Linux**: GCC 15.2 (provided by Nix)
+  - **macOS**: Apple Clang (your system compiler)
 
 The first time you run this command, it will take a few minutes to download and build the environment. Subsequent runs will be much faster.
 
+### Platform notes
+
+- **Linux**: `nix develop` gives you a shell with all the tooling necessary to
+  develop xrpld and with GCC 15.2 (also provided by Nix). There are no caveats.
+- **macOS**: `nix develop` gives you a full environment too. The compiler is
+  your system-wide Apple Clang, while every other tool — including Conan — is
+  provided by Nix. Conan has no binary in the Nix cache for macOS, so it is
+  built from source the first time you enter the shell, which makes the initial
+  setup slower (this is handled automatically; see
+  [`nix/devshell.nix`](../../nix/devshell.nix)).
+
 > [!TIP]
 > To avoid typing `--experimental-features 'nix-command flakes'` every time, you can permanently enable flakes by creating `~/.config/nix/nix.conf`:
 >
@@ -51,7 +65,7 @@ The first time you run this command, it will take a few minutes to download and
 A compiler can be chosen by providing its name with the `.#` prefix, e.g. `nix develop .#gcc15`.
 Use `nix flake show` to see all the available development shells.
 
-Use `nix develop .#no_compiler` to use the compiler from your system.
+Use `nix develop .#no-compiler` to use the compiler from your system.
 
 ### Example Usage
 
@@ -68,12 +82,28 @@ nix develop
 
 ### Using a different shell
 
-`nix develop` opens bash by default. If you want to use another shell this could be done by adding `-c` flag. For example:
+`nix develop` opens bash by default. To use another shell, pass it with the `-c` flag — this works with any shell, e.g. `zsh` or `fish`:
 
 ```bash
+# Use zsh
 nix develop -c zsh
+
+# Use fish
+nix develop -c fish
+
+# Use your login shell
+nix develop -c "$SHELL"
 ```
 
+> [!WARNING]
+> Your shell's interactive startup files (e.g. `config.fish`, `.zshrc`) may prepend other directories — most commonly Homebrew — to `$PATH`, which can shadow the tools provided by the Nix shell. After entering, verify that tools resolve into the Nix store:
+>
+> ```bash
+> command -v cmake   # should print a /nix/store/... path
+> ```
+>
+> If it doesn't, either adjust your shell configuration so it doesn't override `$PATH`, or use [direnv](#automatic-activation-with-direnv) (below), which loads the environment _after_ your shell config and so takes precedence regardless of the shell you use.
+
 ## Building xrpld with Nix
 
 Once inside the Nix development shell, follow the standard [build instructions](../../BUILD.md#steps). The Nix shell provides all necessary tools (CMake, Ninja, Conan, etc.).
@@ -82,6 +112,8 @@ Once inside the Nix development shell, follow the standard [build instructions](
 
 [direnv](https://direnv.net/) or [nix-direnv](https://github.com/nix-community/nix-direnv) can automatically activate the Nix development shell when you enter the repository directory.
 
+This is also the most robust way to use the environment from **any shell** (bash, zsh, fish, …): direnv stays in your current shell and loads the environment _after_ your shell's startup files have run, so the Nix-provided tools take precedence over anything your shell configuration adds to `$PATH`. To use it, install direnv for your shell, then add an `.envrc` containing `use flake` at the repository root and run `direnv allow`.
+
 ## Conan and Prebuilt Packages
 
 Please note that there is no guarantee that binaries from conan cache will work when using nix. If you encounter any errors, please use `--build '*'` to force conan to compile everything from source:
@@ -93,3 +125,8 @@ conan install .. --output-folder . --build '*' --settings build_type=Release
 ## Updating `flake.lock` file
 
 To update `flake.lock` to the latest revision use `nix flake update` command.
+
+## Troubleshooting
+
+See [Troubleshooting Nix problems](./nix_troubleshooting.md) for common issues,
+such as `nix develop` failing inside Git worktrees.

docs/build/nix_troubleshooting.md

@@ -0,0 +1,61 @@
+# Troubleshooting Nix problems
+
+Common issues encountered when using the [Nix development shell](./nix.md), and
+how to resolve them.
+
+## Git worktrees
+
+If `nix develop` fails with an error like:
+
+```
+error:
+       … while fetching the input 'git+file:///path/to/rippled'
+
+       error: opening Git repository "/path/to/rippled": unsupported extension name extensions.relativeworktrees (libgit2 error code = 6)
+```
+
+then your Nix is linked against a libgit2 older than **1.9.4**. Git 2.48+ writes
+the `extensions.relativeWorktrees` config entry when a worktree is created with
+relative paths (`git worktree add --relative-paths`, or with
+`worktree.useRelativePaths=true`), and older libgit2 versions refuse to open a
+repository that uses it. Nix uses libgit2 to read the flake, so evaluation
+fails.
+
+> [!IMPORTANT]
+> This entry is written to the **shared** repository config, so once any
+> relative worktree exists, `nix develop` fails in the main checkout too — not
+> just inside the worktree.
+
+### Workarounds
+
+These work today, with any Nix version:
+
+- bypass libgit2 with a `path:` flakeref: `nix develop "path:$PWD"`
+  (note: this copies the working tree to the store and ignores `.gitignore`); or
+- create worktrees with absolute paths (omit `--relative-paths`); or
+- clear the extension if you don't need relative worktrees:
+  `git config --unset extensions.relativeWorktrees`.
+
+### Permanent fix
+
+The fix is in [libgit2 1.9.4](https://github.com/libgit2/libgit2/releases/tag/v1.9.4),
+so the real solution is a Nix that links against libgit2 `1.9.4` or newer. Check
+which version yours links against:
+
+```bash
+nix-store -qR "$(readlink -f "$(command -v nix)")" | grep libgit2
+```
+
+> [!WARNING]
+> `nix upgrade-nix` does **not** help yet. It installs the build from the
+> official [`nix-fallback-paths`](https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/installer/tools/nix-fallback-paths.nix),
+> which is still linked against libgit2 `1.9.2` — there is no new upstream Nix
+> release with the fix. (On some systems that build is even the exact store path
+> you already have, making the upgrade a no-op.)
+
+nixpkgs has already rebuilt Nix against the fixed libgit2 (e.g. `nix-2.34.7+1`),
+so the cleanest path is to reinstall Nix using your usual installation method
+once it picks up that rebuild, then re-run the `grep libgit2` check above to
+confirm it reports `1.9.4` or newer.
+
+Until then, prefer the workarounds above.

nix/docker/Dockerfile

@@ -71,7 +71,7 @@ if [ ! -e "${target}" ]; then
 fi
 EOF
 
-COPY nix/docker/check-tools.sh /tmp/check-tools.sh
+COPY bin/check-tools.sh /tmp/check-tools.sh
 RUN /tmp/check-tools.sh
 
 # Sanity-check that the g++/clang++ are able to build binaries, including sanitizer-instrumented ones.
@@ -93,7 +93,7 @@ RUN if echo "${BASE_IMAGE}" | grep -qiE 'nixos'; then \
 SHELL ["/bin/bash", "-e", "-o", "pipefail", "-c"]
 
 # Sanity-check that the built binaries run correctly in the vanilla base image, with the necessary sanitizer runtime libraries installed.
-COPY nix/docker/install-sanitizer-libs.sh /tmp/install-sanitizer-libs.sh
+COPY bin/install-sanitizer-libs.sh /tmp/install-sanitizer-libs.sh
 COPY nix/docker/test_files/run-test-binaries.sh /tmp/run-test-binaries.sh
 COPY --from=final /tmp/bins /tmp/bins
 

nix/docker/README.md

@@ -0,0 +1,90 @@
+# Nix CI Docker images
+
+This directory builds the Docker images used by xrpld's Linux CI. Each image
+bundles the **exact same toolchain that the Nix development shell provides**
+(see [`docs/build/nix.md`](../../docs/build/nix.md)), so what runs in CI matches
+what developers get locally from `nix develop`.
+
+The toolchain (CMake, Ninja, Conan, GCC, Clang, clang-tidy, the
+sanitizer/coverage tools, …) is defined in [`nix/packages.nix`](../packages.nix)
+and assembled for CI by [`nix/ci-env.nix`](../ci-env.nix). The Docker build
+turns that Nix environment into an ordinary container image layered on top of a
+conventional base image (Ubuntu, Debian, RHEL, or `nixos/nix`).
+
+## Images
+
+The images are built by the [`build-nix-images.yml`](../../.github/workflows/build-nix-images.yml)
+workflow and pushed to `ghcr.io/xrplf/xrpld/nix-<distro>`. The `<distro>` is
+selected through the `BASE_IMAGE` build argument; the base images are the
+**oldest supported version** of each distribution we target:
+
+| Image        | `BASE_IMAGE`                                 | Notes                                              |
+| ------------ | -------------------------------------------- | -------------------------------------------------- |
+| `nix-nixos`  | `nixos/nix:latest`                           | Build/lint only; binaries are not run (see below). |
+| `nix-ubuntu` | `ubuntu:20.04`                               | Oldest supported Ubuntu (glibc 2.31).              |
+| `nix-debian` | `debian:bookworm`                            |                                                    |
+| `nix-rhel`   | `registry.access.redhat.com/ubi9/ubi:latest` |                                                    |
+
+All images carry the full toolchain on `PATH` (via `/nix/ci-env/bin`) plus the
+CA bundle shipped in the Nix environment, so HTTPS clients (git, curl, Conan)
+work without `ca-certificates` being installed in the base image.
+
+## Build stages
+
+[`Dockerfile`](./Dockerfile) is a multi-stage build:
+
+1. **`builder`** — On a `nixos/nix` builder, evaluate the flake and build the
+   CI environment (`nix/ci-env.nix`). The resulting Nix store closure (the
+   complete set of store paths the toolchain depends on) is copied into a
+   staging directory.
+2. **`final`** — Start from `BASE_IMAGE`, copy in the Nix store closure and the
+   `ci-env` symlink tree, and wire up `PATH` and the CA bundle. It then:
+   - installs the dynamic linker if the base image lacks one (see
+     [How libc is handled](#how-libc-is-handled)),
+   - runs [`bin/check-tools.sh`](../../bin/check-tools.sh) to verify every
+     expected tool is present and runnable, and
+   - compiles the C++ test programs in
+     [`test_files/`](./test_files) with both `g++` and `clang++`, and sanitizers.
+3. **`tester`** — Start again from a clean `BASE_IMAGE` (no Nix toolchain),
+   install only the sanitizer runtime libraries
+   ([`install-sanitizer-libs.sh`](./install-sanitizer-libs.sh)), and run the
+   binaries compiled in `final`. This proves the binaries built with the Nix
+   toolchain actually run on a vanilla base image. On `nixos/nix` this step is
+   skipped (the binaries are patched for a conventional FHS loader).
+4. **Output** — The final image is gated on the tester succeeding: it copies a
+   sentinel file out of `tester`, so a failed test run fails the whole build.
+
+## How libc is handled
+
+The goal is for binaries built in these images to run on the **oldest supported
+base image** (Ubuntu 20.04, glibc 2.31) and newer — without the developer's Nix
+toolchain being present at runtime. Two pieces make that work:
+
+- **Compilers linked against an old glibc.** The Nix CI environment does not use
+  nixpkgs' current glibc. Instead it pins a 2020 nixpkgs snapshot whose primary
+  glibc is **2.31** (matching Ubuntu 20.04), via the `nixpkgs-custom-glibc`
+  flake input. GCC, Clang, binutils and compiler-rt are all rebuilt/wrapped
+  against this custom glibc (see [`nix/ci-env.nix`](../ci-env.nix)). As a result
+  the libraries they emit (`libstdc++`, `libgcc_s`, the sanitizer runtimes)
+  reference only symbols available in glibc 2.31.
+
+- **An expected dynamic linker in the image.**
+  Binaries built in Nix environments reference a dynamic linker from Nix store paths, which won't be present in the base image. However,
+  [`loader-path.sh`](./loader-path.sh) reports the expected loader path for the
+  current architecture, so we can patch the binaries to use the correct loader.
+
+The build then verifies all of this end to end: the test programs in
+`test_files/` (a regular binary plus ASan/TSan/UBSan variants) are compiled in
+`final`, their `PT_INTERP` is patched to the target loader, and they are run in
+the clean `tester` stage to confirm each emits the expected sanitizer
+diagnostic on a stock base image.
+
+## Files
+
+| File                                                                    | Purpose                                                                       |
+| ----------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
+| [`./Dockerfile`](./Dockerfile)                                          | Multi-stage build described above.                                            |
+| [`./loader-path.sh`](./loader-path.sh)                                  | Print the dynamic-linker (`PT_INTERP`) path for the current architecture.     |
+| [`./test_files/`](./test_files)                                         | C++ sources and scripts to compile and run the sanitizer smoke tests.         |
+| [`/bin/check-tools.sh`](../../bin/check-tools.sh)                       | Verify every expected tools are present and runnable.                         |
+| [`/bin/install-sanitizer-libs.sh`](../../bin/install-sanitizer-libs.sh) | Install `libasan`/`libtsan`/`libubsan` runtimes on the supported base images. |

nix/docker/check-tools.sh

@@ -1,39 +0,0 @@
-#!/bin/bash
-# Verify that every tool expected in the Nix CI env is present and runnable.
-set -euo pipefail
-
-ccache --version
-clang --version
-clang++ --version
-clang-format --version
-ClangBuildAnalyzer --version
-cmake --version
-conan --version
-curl --version
-doxygen --version
-file --version
-g++ --version
-gcc --version
-gcov --version
-gcovr --version
-gh --version
-git --version
-git-cliff --version
-gpg --version
-less --version
-make --version
-mold --version
-netstat --version
-ninja --version
-perl --version
-pkg-config --version
-pre-commit --version
-python3 --version
-run-clang-tidy --help
-vim --version
-
-# A simple test to verify that git can clone a repository over HTTPS
-# (i.e. the CA bundle is wired up). Clone to a temp dir and clean up.
-tmp_clone="$(mktemp -d)"
-git clone --depth 1 https://github.com/XRPLF/actions.git "${tmp_clone}/actions"
-rm -rf "${tmp_clone}"

nix/packages.nix

@@ -19,6 +19,7 @@ in
     gh
     git
     git-cliff
+    git-lfs
     gnumake
     gnupg # needed for signing commits & codecov/codecov-action
     llvmPackages_22.clang-tools
@@ -33,5 +34,6 @@ in
     python3
     runClangTidy
     vim
+    zip
   ];
 }