Skip to content

build(cmake): honour SOURCE_DATE_EPOCH for reproducible distro builds#3165

Merged
ten9876 merged 1 commit into
mainfrom
auto/source-date-epoch
May 25, 2026
Merged

build(cmake): honour SOURCE_DATE_EPOCH for reproducible distro builds#3165
ten9876 merged 1 commit into
mainfrom
auto/source-date-epoch

Conversation

@ten9876

@ten9876 ten9876 commented May 25, 2026

Copy link
Copy Markdown
Collaborator

Summary

Distros that participate in reproducible-builds.org (Debian, Arch, NixOS, openSUSE, Fedora, etc.) set SOURCE_DATE_EPOCH before invoking cmake to make __DATE__ / __TIME__ deterministic. GCC 7.2+ and Clang already honour the env var at the compiler level — no source-tree changes are needed for AetherSDR to produce reproducible builds under these packagers' standard pipelines.

This change is just a configure-time status line so packagers can confirm at a glance that their env-var actually reached the build:

```
$ SOURCE_DATE_EPOCH=$(git log -1 --format=%ct) cmake -B build -S .

-- Build SHA: 8b0c2d5
-- Reproducible build: honoring SOURCE_DATE_EPOCH=1717238400

```

Unset → no diff vs. main.

Context

Closes the ecosystem-standard alternative to #3139, where @dawkagaming proposed a project-specific BUILD_TIMESTAMPS opt-out flag to suppress `DATE` for reproducibility. The counter-proposal in #3139's review thread laid out why SOURCE_DATE_EPOCH is preferable:

  1. Universal: every packager already knows it from non-AetherSDR work
  2. No source-file `#ifdef` branches — the toolchain handles substitution
  3. Preserves real compile-date info for end users; no `"---"` placeholders in About
  4. Covers more than `DATE` — `TIME`, `ar`/`ld` link timestamps, deterministic-archive tooling all honour it
  5. Doesn't conflate the git SHA — the SHA is already deterministic from the source tree

@dawkagaming closed #3139 in favour of this approach. Credit to him for surfacing the reproducibility problem in the first place — the implementation took a different shape but the diagnosis was correct.

Test plan

  • Configure without `SOURCE_DATE_EPOCH`: no diff vs. main (no status line, no behavior change)
  • Configure with `SOURCE_DATE_EPOCH=1717238400`: prints "Reproducible build: honoring …"
  • Full build (`--target AetherSDR`) clean
  • No source-tree changes (no `#ifdef`s, no preprocessor branching)

🤖 Generated with Claude Code

Distros that participate in reproducible-builds.org (Debian, Arch,
NixOS, openSUSE, Fedora, etc.) set SOURCE_DATE_EPOCH before invoking
cmake to make `__DATE__` / `__TIME__` deterministic.  GCC 7.2+ and
Clang already honour the env var at the compiler level — no source-
tree changes are needed for AetherSDR to produce reproducible builds
under these packagers' standard pipelines.

This change is just a configure-time status line so packagers can
confirm at a glance that their env-var actually reached the build.
With `-DSOURCE_DATE_EPOCH=…` exported, configure now prints:

    -- Reproducible build: honoring SOURCE_DATE_EPOCH=…

Unset → no diff vs. main.  Tested both code paths locally on
Cachy/Wayland (Qt 6.9, CMake 3.31).

Closes the ecosystem-standard alternative to #3139, which proposed
a project-specific BUILD_TIMESTAMPS flag instead.  @dawkagaming
surfaced the reproducibility problem in the first place — credit to
him for the diagnosis even though the implementation took a
different shape.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@ten9876 ten9876 requested a review from a team as a code owner May 25, 2026 21:22
@ten9876 ten9876 merged commit 892f028 into main May 25, 2026
5 checks passed
@ten9876 ten9876 deleted the auto/source-date-epoch branch May 25, 2026 21:53
G6PWY-Chris pushed a commit to G6PWY-Chris/AetherSDR that referenced this pull request Jun 22, 2026
…aethersdr#3165)

## Summary

Distros that participate in
[reproducible-builds.org](https://reproducible-builds.org/) (Debian,
Arch, NixOS, openSUSE, Fedora, etc.) set `SOURCE_DATE_EPOCH` before
invoking cmake to make `__DATE__` / `__TIME__` deterministic. GCC 7.2+
and Clang [already honour the env
var](https://gcc.gnu.org/onlinedocs/cpp/Environment-Variables.html) at
the compiler level — no source-tree changes are needed for AetherSDR to
produce reproducible builds under these packagers' standard pipelines.

This change is just a configure-time status line so packagers can
confirm at a glance that their env-var actually reached the build:

\`\`\`
$ SOURCE_DATE_EPOCH=\$(git log -1 --format=%ct) cmake -B build -S .
…
-- Build SHA: 8b0c2d5
-- Reproducible build: honoring SOURCE_DATE_EPOCH=1717238400
…
\`\`\`

Unset → no diff vs. main.

## Context

Closes the ecosystem-standard alternative to aethersdr#3139, where @dawkagaming
proposed a project-specific `BUILD_TIMESTAMPS` opt-out flag to suppress
\`__DATE__\` for reproducibility. The counter-proposal in aethersdr#3139's review
thread laid out why `SOURCE_DATE_EPOCH` is preferable:

1. **Universal**: every packager already knows it from non-AetherSDR
work
2. **No source-file \`#ifdef\` branches** — the toolchain handles
substitution
3. **Preserves real compile-date info** for end users; no \`"---"\`
placeholders in About
4. **Covers more than \`__DATE__\`** — \`__TIME__\`, \`ar\`/\`ld\` link
timestamps, deterministic-archive tooling all honour it
5. **Doesn't conflate the git SHA** — the SHA is already deterministic
from the source tree

@dawkagaming closed aethersdr#3139 in favour of this approach. Credit to him for
surfacing the reproducibility problem in the first place — the
implementation took a different shape but the diagnosis was correct.

## Test plan

- [x] Configure without \`SOURCE_DATE_EPOCH\`: no diff vs. main (no
status line, no behavior change)
- [x] Configure with \`SOURCE_DATE_EPOCH=1717238400\`: prints
"Reproducible build: honoring …"
- [x] Full build (\`--target AetherSDR\`) clean
- [x] No source-tree changes (no \`#ifdef\`s, no preprocessor branching)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant