Add option to not include build timestamp#3139
Conversation
There was a problem hiding this comment.
Thanks for the contribution, @dawkagaming — reproducible builds for Debian packaging is a worthwhile goal. A few items to address:
1. option() is missing the help string (CMakeLists.txt:10)
option(NO_BUILD_TIMESTAMP OFF)The signature is option(<variable> "<help_text>" [initial_value]). As written, CMake takes "OFF" as the help text and the initial value falls through to the default (also OFF), so it happens to behave correctly — but the help string is wrong, which will surface in ccmake/cmake-gui. Please change to:
option(NO_BUILD_TIMESTAMP "Omit __DATE__ from the binary for reproducible builds" OFF)2. A second __DATE__ site is not gated
src/core/SupportBundle.cpp:30 also embeds __DATE__ into the compiled binary:
QString::fromLatin1(__DATE__)With NO_BUILD_TIMESTAMP=ON, this site will still bake the build date into the binary and break reproducibility. The flag needs to gate this one too (replace with "---" or similar in the same way).
3. Consider naming convention
Inverted booleans (NO_* defaulting OFF) read awkwardly. A positive BUILD_TIMESTAMP defaulting ON matches CMake idiom better, but this is a style point — defer to maintainer preference.
4. Worth knowing: GCC/Clang already honor SOURCE_DATE_EPOCH for __DATE__/__TIME__ expansion, which is what Debian's reproducible-builds toolchain sets automatically. So Debian packagers may not need this flag at all — but having an explicit opt-out is still useful for other distros and for clarity, so the PR direction is fine.
Once items 1 and 2 are addressed this should be ready. Thanks!
🤖 aethersdr-agent · cost: $7.1259 · model: claude-opus-4-7
1be65f3 to
c5df0a2
Compare
|
Claude here. First — Dawid, thank you for the sustained effort here. Looking at the arc of your contributions (#3074, #3135, #3138, #3139, #3143), it's clear you're working on making AetherSDR genuinely packageable on Linux distros, and every one of those PRs has a real standard or convention behind it. That's exactly the kind of contribution this project needs but doesn't get organically from the radio-operator user base. Whether you end up landing AetherSDR in Debian, Arch's AUR, or a Polish-mirror repo, the work matters and we're grateful for it. On this specific PR — the concern is 100% legitimate. The implementation we'd prefer, though, leans on the ecosystem's existing convention rather than a project-specific flag. The canonical mechanism is the # This is the exact invocation Debian, Arch, Nix, etc. already use for every package
SOURCE_DATE_EPOCH=$(git log -1 --format=%ct) cmake --build .The advantages over
A minimal counter-proposal that gives downstream packagers the canonical interface (and a status line so they can confirm at configure time that reproducibility mode is active): # In CMakeLists.txt, near where AETHER_GIT_SHA is set:
if(DEFINED ENV{SOURCE_DATE_EPOCH})
message(STATUS "Reproducible build: honoring SOURCE_DATE_EPOCH=$ENV{SOURCE_DATE_EPOCH}")
# No source changes needed — GCC 7.2+ / Clang substitute __DATE__ and __TIME__
# automatically when this env var is set. This message just confirms that
# the configure step saw the var, for downstream packagers' sanity.
endif()That's the entire diff. No source-file Would you be open to revising the PR along those lines? If you'd rather we take it from here, no problem — happy to land the env-var version with credit to you for surfacing the issue. Either path is fine; the important thing is the project gets the standards-compliant fix. Also: separately reviewing your other open packaging PRs (#3138 lowercase binary, #3143 256x256 icon) — both look like clean wins, going to take a closer look this week. 73, Jeremy KK7GWY & Claude (AI dev partner) |
…#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 #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 - [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>
…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>
Hello,
As timestamping can make the reproducible builds fail, I think it is a good idea to add an option for it,
especially as Debian is preferring reproducible builds now.
Thanks,
Dawid SP9SKA