build: configure on cmake 3.22 (Ubuntu 22.04 LTS) - #27
Merged
Conversation
The eigen FetchContent block already branches on cmake version -- a 3.28+ path
using SOURCE_SUBDIR, and a pre-3.28 fallback using FetchContent_Populate. But
both paths passed DOWNLOAD_EXTRACT_TIMESTAMP TRUE unconditionally, and that
argument arrived in 3.24. So the fallback was never actually reachable below
3.24, and the floor had to say 3.24 to match.
That excluded Ubuntu 22.04 LTS, which ships cmake 3.22.1.
The argument exists because CMP0135, new in 3.24, changed URL extraction to
stamp files with the extraction time rather than the archive's own timestamps.
Passing TRUE asks for the older behaviour -- which, below 3.24, is simply the
default. So on 3.22 the argument is both unavailable and unnecessary, and
omitting it is exactly equivalent rather than a compromise.
Hoisted it into a variable set only when the running cmake is 3.24 or newer,
used in both Declare calls, and brought the floor down to 3.22 to match. The
3.28 branch is untouched.
Testing and Verification Instructions:
1. macOS, cmake 4.x -- clean build, 156/156 tests, identical to before.
2. Ubuntu 22.04 LTS, cmake 3.22.1 -- configures and builds where it
previously refused at the first line of this file.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
28a34a1..41215c6 The pinned dsptap declared a 3.24 floor, and a nested submodule refuses first, so lowering this repo's own floor was not enough on its own -- a stock Ubuntu 22.04 LTS machine (cmake 3.22.1) still failed to configure. dsptap is 3.22 upstream now, so this moves the pin. Together with the previous commit the whole tree configures on 3.22. The range also carries three commits already on dsptap main: two vDSP FFT fixes and a CI/build change. The suite is unchanged across the bump -- 156/156 before and after. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Two commits, both aimed at one thing — configuring on Ubuntu 22.04 LTS
(cmake 3.22.1), which this repo currently cannot do.
DOWNLOAD_EXTRACT_TIMESTAMPbehind a version check, and lowercmake_minimum_requiredto 3.22.dsptappin,28a34a1..41215c6.Why the argument can simply be omitted below 3.24
The eigen
FetchContentblock already branches on cmake version — a 3.28+ pathusing
SOURCE_SUBDIR, and a pre-3.28 fallback usingFetchContent_Populate.But both paths passed
DOWNLOAD_EXTRACT_TIMESTAMP TRUEunconditionally, andthat argument arrived in 3.24. So the fallback was never reachable below 3.24,
and the floor had to say 3.24 to match.
That argument exists because CMP0135 (new in 3.24) changed URL extraction to
stamp files with the extraction time rather than the archive's own timestamps.
Passing
TRUEasks for the older behaviour — which, below 3.24, is simply thedefault. So on 3.22 it's both unavailable and unnecessary: omitting it is exactly
equivalent, not a compromise.
It's now hoisted into a variable set only when the running cmake is ≥ 3.24, used
in both
Declarecalls. The 3.28 branch is otherwise untouched.Why the pin bump is needed too
dsptapdeclared the same 3.24 floor, and a nested submodule refuses first — sothe change above wasn't sufficient on its own. dsptap is 3.22 upstream now.
The range carries three commits already on dsptap
main: two vDSP FFT fixes anda CI/build change.
Verification
Identical test counts on macOS across both commits — the point being that two of
the carried dsptap commits touch the vDSP FFT path, and nothing moved.
🤖 Generated with Claude Code