Policy layer and build recipes for building ATLAS Athena with bits,
using lcg.bits as the external-package pool. Like
key4hep.bits it is a policy repository — it ships almost no
package recipes of its own and points at the ~1100 recipes in lcg.bits. Unlike
key4hep.bits, it does not enumerate a per-package stack: Athena is built as
ATLAS builds it — two large CMake super-projects driven by ATLAS's own scripts —
so atlas.bits wraps those scripts rather than replacing them.
The goal is to move the ATLAS build onto a bits backend without changing how
users interact with their build scripts: athena/Projects/Athena/build_externals.sh
and build.sh run unchanged; only the LCG release they resolve against is supplied
by bits instead of /cvmfs/sft.cern.ch/lcg/releases.
- Repository Discovery & Provider Model
- How the ATLAS build works on bits
- The
defaults-release.shProfile - The
defaults-atlas.shOverlay (LCG_110_ATLAS_5) - The LCG view — satisfying
find_package(LCG) - The Recipes:
atlasexternals.shandathena.sh - Branches and Releases
- Command-Line Usage
- Local Development
- Publishing to CVMFS
- Files Overview
bits resolves recipes along an ordered search path (BITS_PATH). A repository can
be pulled in on demand by a repository-provider package — an ordinary recipe with
provides_repository: true whose source points at a recipe repo. lcg.bits is
such a package, so atlas.bits only has to require it:
# defaults-release.sh
requires:
- lcg.bits
overrides:
lcg.bits:
tag: "%(release)s" # the release label selects the recipe-pool branchThe chain resolved for an Athena build is one hop:
atlas.bits ──requires──▶ lcg.bits (LCG_110 recipe pool: ROOT, Geant4, Boost, …)
│
└── defaults-release.sh, defaults-atlas.sh, lcg-view.sh,
atlasexternals.sh, athena.sh (this repo)
%(release)s resolves to LCG_110 (see Branches and Releases),
which must exist as an lcg.bits branch — that branch is the LCG 110 recipe pool.
ATLAS builds Athena as two CMake super-projects, both consuming an LCG release as their external base:
Projects/Athena/build_externals.shbuilds AthenaExternals (fromatlas/atlasexternals, version pinned inProjects/Athena/externals.txt), layering ATLAS's own Gaudi fork, ACTS, GeoModel and vecmem on top of an LCG release found viafind_package(LCG 110 EXACT)(postfix_ATLAS_5).Projects/Athena/build.shbuilds Athena (version inProjects/Athena/version.txt) on top of AthenaExternals.
atlas.bits maps this onto bits as:
lcg.bits (LCG_110) ──▶ lcg-view ──▶ atlasexternals ──▶ Athena
recipe pool LCG manifest build_externals.sh build.sh
lcg-view presents the bits-built LCG closure in the layout ATLAS's
find_package(LCG) expects, so ATLAS's CMake and scripts run unmodified — the
only thing that changes is that the LCG base comes from bits (and its signed,
content-addressed store) rather than the SFT CVMFS release.
The base profile every build inherits. It declares the ATLAS CVMFS publish layout
and the lcg.bits provider. The system: block (never folded into package hashes)
holds the publish policy:
prefix: /cvmfs/bits.cern.ch/atlas
releases: {prefix}/{release}/{family}{pkg}/{tag}/{platform}
modules: {prefix}/{release}/{platform}/Modules/modulefiles/{pkg}
shared: {prefix}/{release}/noarch/{pkg}/{tag}
This is the LCG-style layout (with {release} and {family} segments), unlike the
flatter Key4hep one. prefix is an auth boundary injected by bits-console; the
value here must match the community's ui-config.yaml.
Composed with --defaults atlas, this overlay carries the ATLAS-specific policy:
release: LCG_110— thelcg.bitsbranch to build against.LCG_PLATFORM/LCG_VERSION_POSTFIX=_ATLAS_5— sofind_package(LCG 110 EXACT)finds a directoryLCG_110_ATLAS_5and theLCG_externals_<platform>.txtmanifest.overrides:— the_ATLAS_5externals deltas (lcgcmakeheptools-110_ATLAS_5.cmake) applied on top of the shared base LCG_110 branch: version pins for the ATLAS generators and the CUDA stack.disable:—DD4hepandacts(AthenaExternals builds its own GeoModel and ACTS v47.6.1), plusR,rpy2,onnxruntime,tf2onnx.
Keeping these deltas in atlas.bits (rather than in lcg.bits) means the shared
lcg.bits LCG_110 branch stays the neutral base LCG 110, and ATLAS's choices ride
on top — other communities using the same pool are unaffected.
Patch-coupled entries. The ATLAS author-patched generators (
epos4,hijing,madgraph5amc) pin.atlasNversions that require the matching author patch in thelcg.bitsrecipe; the recipes currently carry the older patch, so these will not build until the recipe is updated. They are pinned in the overlay to record the target.tauola++(lcg.bits/tauolacpp.sh) and thejax_cuda12_*packages are named by_ATLAS_5but need recipe work too.
ATLAS's find_package(LCG 110 EXACT) (config-mode, atlasexternals/Build/AtlasLCG/ LCGConfig.cmake) reads, under $LCG_RELEASE_BASE:
LCG_110_ATLAS_5/LCG_externals_<platform>.txt # name;hash;version;dir;deps
LCG_110_ATLAS_5/LCG_generators_<platform>.txt
and sets each <PKG>_LCGROOT from field 4 (dir), which may be an absolute
path. lcg-view.sh emits exactly these manifests over the bits LCG closure,
with dir pointing straight at the bits install prefixes — no symlink farm and
no CMake from us; AtlasLCG (shipped by ATLAS) is the resolver. lcg-view exports
LCG_RELEASE_BASE, so the view is materialised locally, before any publish,
and bits build Athena works from the local cache.
The manifest lines are produced by a bits lcg-view-manifest helper (the one new
piece of bits code this use case needs — the versions/hashes/deps live in the
resolved specs, not in a recipe's shell env).
Both check out atlas/athena and drive ATLAS's own scripts, so the build is exactly
what an ATLAS developer would run:
| recipe | version from | runs | requires |
|---|---|---|---|
atlasexternals |
externals.txt (AthenaExternalsVersion) |
Projects/Athena/build_externals.sh |
lcg-view |
Athena |
version.txt |
Projects/Athena/build.sh |
atlasexternals |
Both set sandbox_network: "off" (network allowed — build_externals.sh clones
atlasexternals and downloads the Gaudi/ACTS/GeoModel/vecmem tarballs). This is
against bits' reproducible default; the cleaner end state is to prefetch those and
keep the sandbox closed.
The release label names the lcg.bits branch to build against and the CVMFS
{release} path segment. bits resolves it highest-precedence-first: an explicit
release: in the defaults (here LCG_110) → the working-directory branch name →
main. The effective release must exist as an lcg.bits branch.
bits deps Athena --defaults atlas::gcc15 # inspect the dependency tree
bits build atlasexternals --defaults atlas::gcc15 # the externals layer only
bits build Athena --defaults atlas::gcc15 # externals + Athenarelease is the implicit base profile; overlay it with the compiler/build-type axes
(gcc15, dbg, …) from stacks.bits. ATLAS targets x86_64-el9-gcc15-opt.
Build with bits; explore the result with bitsenv (Environment Modules front-end):
bitsenv q # list built modules
bitsenv enter Athena/25.0.72 # subshell with the module(s) loaded
eval `bitsenv printenv Athena/25.0.72`After a local build, the standard ATLAS runtime setup still applies:
asetup Athena,25.0.72 --releasepath=<build>/install --siteroot=<LCG view>The LCG view has two renderings of the same manifest: the absolute-path form
(two text files whose dir fields point at the local sw/ prefixes — used for the
local pre-publish build) and the relocatable form (relative dir + a symlink
farm, i.e. bits publish --release-view) for the CVMFS release tree. Publishing is
a follow-on to a working local build, not a prerequisite for it.
| File | Purpose |
|---|---|
defaults-release.sh |
base profile: ATLAS CVMFS layout + lcg.bits provider |
defaults-atlas.sh |
ATLAS group overlay: LCG_110 _ATLAS_5 deltas + disables |
lcg-view.sh |
emits the LCG_110_ATLAS_5 manifest over the bits LCG closure |
atlasexternals.sh |
AthenaExternals via ATLAS's build_externals.sh |
athena.sh |
Athena via ATLAS's build.sh |
Compiler/build-type axis profiles (gcc15, dbg, cuda, …) are not shipped here — they are inherited from stacks.bits when it is on BITS_PATH.