Skip to content

getdeps: bump sparsemap to 0.7.0 for CMake 4 - #493

Closed
michel-slm wants to merge 1 commit into
facebook:mainfrom
michel-slm:getdeps-sparsemap-0.7.0
Closed

getdeps: bump sparsemap to 0.7.0 for CMake 4#493
michel-slm wants to merge 1 commit into
facebook:mainfrom
michel-slm:getdeps-sparsemap-0.7.0

Conversation

@michel-slm

@michel-slm michel-slm commented Sep 16, 2026

Copy link
Copy Markdown
Contributor

sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to #488/#490/#491. The CMake version matrix behind the platform list is in facebook/folly#2703.

🤖 Generated with Claude Code

@michel-slm @claude
getdeps: bump sparsemap to 0.7.0 for CMake 4
90b21b5 
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4
removed compatibility with anything below 3.5, so on hosts whose system
CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon
Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

  CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
    Compatibility with CMake < 3.5 has been removed from CMake.

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake
3.10, so take the release rather than carry a patch. 0.7.0 also moves to
C++17, fixes iterator invalidation on a non-inserting insert and the
serialization of small hashes, and adds a no-exceptions mode; the
headers install to the same include/tsl layout. cachelib is the only
manifest that depends on sparsemap, and the one internal type it reaches
into, tsl::detail_sparse_hash::sparse_array, keeps the same template
parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no
CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line:
`getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib`
configured and installed sparsemap 0.7.0 with no CMake error (the only
CMake output of note being the < 3.10 deprecation warnings from fizz and
wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp
against the new headers with -Werror on, and linked cachebench; 51
minutes at two jobs.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: Michel Lind <salimma@fedoraproject.org>
@meta-cla meta-cla Bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Sep 16, 2026
@meta-codesync

meta-codesync Bot commented Sep 16, 2026

Copy link
Copy Markdown
Contributor

@michel-slm has imported this pull request. If you are a Meta employee, you can view this in D120425085.

bigfootjon
bigfootjon approved these changes Sep 16, 2026
View reviewed changes

@bigfootjon bigfootjon left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review automatically exported from Phabricator review in Meta.

meta-codesync Bot pushed a commit to facebook/BGP that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: bump sparsemap to 0.7.0 for CMake 4
7364f6a 
Summary:
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

```
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
```

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to facebook/CacheLib#488. The CMake version matrix behind the platform list is in facebook/folly#2703.

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

X-link: facebook/CacheLib#493

Reviewed By: bigfootjon

Differential Revision: D120425085

Pulled By: michel-slm

fbshipit-source-id: 9802415458f4d6ba20fab21630ec9047d7ba45d5
meta-codesync Bot pushed a commit to facebook/fb303 that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: bump sparsemap to 0.7.0 for CMake 4
b403396 
Summary:
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

```
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
```

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to facebook/CacheLib#488. The CMake version matrix behind the platform list is in facebook/folly#2703.

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

X-link: facebook/CacheLib#493

Reviewed By: bigfootjon

Differential Revision: D120425085

Pulled By: michel-slm

fbshipit-source-id: 9802415458f4d6ba20fab21630ec9047d7ba45d5
meta-codesync Bot pushed a commit to facebook/openr that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: bump sparsemap to 0.7.0 for CMake 4
5f09a55 
Summary:
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

```
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
```

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to facebook/CacheLib#488. The CMake version matrix behind the platform list is in facebook/folly#2703.

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

X-link: facebook/CacheLib#493

Reviewed By: bigfootjon

Differential Revision: D120425085

Pulled By: michel-slm

fbshipit-source-id: 9802415458f4d6ba20fab21630ec9047d7ba45d5
meta-codesync Bot pushed a commit to facebook/rebalancer that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: bump sparsemap to 0.7.0 for CMake 4
4bb79b1 
Summary:
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

```
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
```

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to facebook/CacheLib#488. The CMake version matrix behind the platform list is in facebook/folly#2703.

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

X-link: facebook/CacheLib#493

Reviewed By: bigfootjon

Differential Revision: D120425085

Pulled By: michel-slm

fbshipit-source-id: 9802415458f4d6ba20fab21630ec9047d7ba45d5
meta-codesync Bot pushed a commit to facebook/fboss that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: bump sparsemap to 0.7.0 for CMake 4
f244017 
Summary:
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

```
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
```

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to facebook/CacheLib#488. The CMake version matrix behind the platform list is in facebook/folly#2703.

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

X-link: facebook/CacheLib#493

Reviewed By: bigfootjon

Differential Revision: D120425085

Pulled By: michel-slm

fbshipit-source-id: 9802415458f4d6ba20fab21630ec9047d7ba45d5
meta-codesync Bot pushed a commit to facebook/watchman that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: bump sparsemap to 0.7.0 for CMake 4
fd2b1e2 
Summary:
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

```
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
```

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to facebook/CacheLib#488. The CMake version matrix behind the platform list is in facebook/folly#2703.

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

X-link: facebook/CacheLib#493

Reviewed By: bigfootjon

Differential Revision: D120425085

Pulled By: michel-slm

fbshipit-source-id: 9802415458f4d6ba20fab21630ec9047d7ba45d5
meta-codesync Bot pushed a commit to facebook/mvfst that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: bump sparsemap to 0.7.0 for CMake 4
29fe5b8 
Summary:
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

```
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
```

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to facebook/CacheLib#488. The CMake version matrix behind the platform list is in facebook/folly#2703.

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

X-link: facebook/CacheLib#493

Reviewed By: bigfootjon

Differential Revision: D120425085

Pulled By: michel-slm

fbshipit-source-id: 9802415458f4d6ba20fab21630ec9047d7ba45d5
meta-codesync Bot pushed a commit to facebookexperimental/edencommon that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: bump sparsemap to 0.7.0 for CMake 4
6839d75 
Summary:
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

```
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
```

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to facebook/CacheLib#488. The CMake version matrix behind the platform list is in facebook/folly#2703.

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

X-link: facebook/CacheLib#493

Reviewed By: bigfootjon

Differential Revision: D120425085

Pulled By: michel-slm

fbshipit-source-id: 9802415458f4d6ba20fab21630ec9047d7ba45d5
meta-codesync Bot pushed a commit to facebook/wangle that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: bump sparsemap to 0.7.0 for CMake 4
d4bd756 
Summary:
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

```
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
```

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to facebook/CacheLib#488. The CMake version matrix behind the platform list is in facebook/folly#2703.

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

X-link: facebook/CacheLib#493

Reviewed By: bigfootjon

Differential Revision: D120425085

Pulled By: michel-slm

fbshipit-source-id: 9802415458f4d6ba20fab21630ec9047d7ba45d5
meta-codesync Bot pushed a commit to facebookexperimental/rust-shed that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: bump sparsemap to 0.7.0 for CMake 4
9cc4993 
Summary:
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

```
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
```

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to facebook/CacheLib#488. The CMake version matrix behind the platform list is in facebook/folly#2703.

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

X-link: facebook/CacheLib#493

Reviewed By: bigfootjon

Differential Revision: D120425085

Pulled By: michel-slm

fbshipit-source-id: 9802415458f4d6ba20fab21630ec9047d7ba45d5
meta-codesync Bot pushed a commit to facebook/folly that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: bump sparsemap to 0.7.0 for CMake 4
ed887bd 
Summary:
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

```
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
```

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in #2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to facebook/CacheLib#488. The CMake version matrix behind the platform list is in #2703.

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

X-link: facebook/CacheLib#493

Reviewed By: bigfootjon

Differential Revision: D120425085

Pulled By: michel-slm

fbshipit-source-id: 9802415458f4d6ba20fab21630ec9047d7ba45d5
meta-codesync Bot pushed a commit to facebook/fbthrift that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: bump sparsemap to 0.7.0 for CMake 4
43577a8 
Summary:
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

```
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
```

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to facebook/CacheLib#488. The CMake version matrix behind the platform list is in facebook/folly#2703.

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

X-link: facebook/CacheLib#493

Reviewed By: bigfootjon

Differential Revision: D120425085

Pulled By: michel-slm

fbshipit-source-id: 9802415458f4d6ba20fab21630ec9047d7ba45d5
@meta-codesync meta-codesync Bot closed this in 1cf41f3 Sep 17, 2026
meta-codesync Bot pushed a commit to facebookexperimental/moxygen that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: bump sparsemap to 0.7.0 for CMake 4
1e26968 
Summary:
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

```
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
```

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to facebook/CacheLib#488. The CMake version matrix behind the platform list is in facebook/folly#2703.

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

X-link: facebook/CacheLib#493

Reviewed By: bigfootjon

Differential Revision: D120425085

Pulled By: michel-slm

fbshipit-source-id: 9802415458f4d6ba20fab21630ec9047d7ba45d5
@meta-codesync meta-codesync Bot added the Merged label Sep 17, 2026
@meta-codesync

meta-codesync Bot commented Sep 17, 2026

Copy link
Copy Markdown
Contributor

@michel-slm merged this pull request in 1cf41f3.

meta-codesync Bot pushed a commit to facebookincubator/hsthrift that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: bump sparsemap to 0.7.0 for CMake 4
1544723 
Summary:
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

```
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
```

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to facebook/CacheLib#488. The CMake version matrix behind the platform list is in facebook/folly#2703.

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

X-link: facebook/CacheLib#493

Reviewed By: bigfootjon

Differential Revision: D120425085

Pulled By: michel-slm

fbshipit-source-id: 9802415458f4d6ba20fab21630ec9047d7ba45d5
meta-codesync Bot pushed a commit to facebookincubator/katran that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: bump sparsemap to 0.7.0 for CMake 4
635dea0 
Summary:
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

```
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
```

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to facebook/CacheLib#488. The CMake version matrix behind the platform list is in facebook/folly#2703.

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

X-link: facebook/CacheLib#493

Reviewed By: bigfootjon

Differential Revision: D120425085

Pulled By: michel-slm

fbshipit-source-id: 9802415458f4d6ba20fab21630ec9047d7ba45d5
meta-codesync Bot pushed a commit to facebookincubator/fizz that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: bump sparsemap to 0.7.0 for CMake 4
5fe2cb5 
Summary:
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

```
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
```

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to facebook/CacheLib#488. The CMake version matrix behind the platform list is in facebook/folly#2703.

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

X-link: facebook/CacheLib#493

Reviewed By: bigfootjon

Differential Revision: D120425085

Pulled By: michel-slm

fbshipit-source-id: 9802415458f4d6ba20fab21630ec9047d7ba45d5
meta-codesync Bot pushed a commit to facebook/proxygen that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: bump sparsemap to 0.7.0 for CMake 4
ac9207f 
Summary:
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

```
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
```

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to facebook/CacheLib#488. The CMake version matrix behind the platform list is in facebook/folly#2703.

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

X-link: facebook/CacheLib#493

Reviewed By: bigfootjon

Differential Revision: D120425085

Pulled By: michel-slm

fbshipit-source-id: 9802415458f4d6ba20fab21630ec9047d7ba45d5
meta-codesync Bot pushed a commit to facebook/sapling that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: bump sparsemap to 0.7.0 for CMake 4
dc41b2a 
Summary:
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

```
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
```

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to facebook/CacheLib#488. The CMake version matrix behind the platform list is in facebook/folly#2703.

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

X-link: facebook/CacheLib#493

Reviewed By: bigfootjon

Differential Revision: D120425085

Pulled By: michel-slm

fbshipit-source-id: 9802415458f4d6ba20fab21630ec9047d7ba45d5
meta-codesync Bot pushed a commit to facebook/hhvm that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: bump sparsemap to 0.7.0 for CMake 4
7465a39 
Summary:
sparse-map 0.6.2 declares cmake_minimum_required(VERSION 3.1). CMake 4 removed compatibility with anything below 3.5, so on hosts whose system CMake is 4.x (Fedora 44, Homebrew, the GitHub macOS runners, and soon Ubuntu 26.04 and Debian 14) the sparsemap step fails to configure:

```
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.
```

Upstream fixed this in 0.7.0 (released 2025-11-02), which requires CMake 3.10, so take the release rather than carry a patch. 0.7.0 also moves to C++17, fixes iterator invalidation on a non-inserting insert and the serialization of small hashes, and adds a no-exceptions mode; the headers install to the same include/tsl layout. cachelib is the only manifest that depends on sparsemap, and the one internal type it reaches into, tsl::detail_sparse_hash::sparse_array, keeps the same template parameters.

Tested on Fedora 44 with system CMake 4.3.0 and gcc 15, no CMAKE_POLICY_VERSION_MINIMUM anywhere on the command line: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` configured and installed sparsemap 0.7.0 with no CMake error (the only CMake output of note being the < 3.10 deprecation warnings from fizz and wangle, tracked in facebook/folly#2703), compiled SparseMapIndex.cpp against the new headers with -Werror on, and linked cachebench; 51 minutes at two jobs.

Manifest-only change; follow-up to facebook/CacheLib#488. The CMake version matrix behind the platform list is in facebook/folly#2703.

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

X-link: facebook/CacheLib#493

Reviewed By: bigfootjon

Differential Revision: D120425085

Pulled By: michel-slm

fbshipit-source-id: 9802415458f4d6ba20fab21630ec9047d7ba45d5
@michel-slm michel-slm mentioned this pull request Sep 17, 2026
Closed
meta-codesync Bot pushed a commit that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged (#…
646152d 
…494)

Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to #488 and #493. RHEL hosts only benefit once #495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

Pull Request resolved: #494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot pushed a commit to facebook/fb303 that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged
756eca6 
Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

X-link: facebook/CacheLib#494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot pushed a commit to facebook/wangle that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged
b529f25 
Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

X-link: facebook/CacheLib#494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot pushed a commit to facebook/BGP that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged
9af7ef5 
Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

X-link: facebook/CacheLib#494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot pushed a commit to facebook/openr that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged
9fc4093 
Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

X-link: facebook/CacheLib#494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot pushed a commit to facebookexperimental/edencommon that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged
df07635 
Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

X-link: facebook/CacheLib#494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot pushed a commit to facebook/folly that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged
6bf0fc0 
Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

X-link: facebook/CacheLib#494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot pushed a commit to facebookexperimental/rust-shed that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged
f561751 
Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

X-link: facebook/CacheLib#494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot pushed a commit to facebookincubator/hsthrift that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged
7ecd045 
Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

X-link: facebook/CacheLib#494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot pushed a commit to facebook/rebalancer that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged
ed30d34 
Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

X-link: facebook/CacheLib#494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot pushed a commit to facebookincubator/fizz that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged
11066a0 
Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

X-link: facebook/CacheLib#494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot pushed a commit to facebook/fbthrift that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged
81d4943 
Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

X-link: facebook/CacheLib#494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot pushed a commit to facebook/mvfst that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged
3731b45 
Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

X-link: facebook/CacheLib#494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot pushed a commit to facebook/watchman that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged
55091af 
Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

X-link: facebook/CacheLib#494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot pushed a commit to facebook/sapling that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged
d9082d9 
Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

X-link: facebook/CacheLib#494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot pushed a commit to facebook/hhvm that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged
54ae458 
Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

X-link: facebook/CacheLib#494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot pushed a commit to facebookincubator/katran that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged
6d47373 
Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

X-link: facebook/CacheLib#494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot pushed a commit to facebook/fboss that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged
b7e9e08 
Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

X-link: facebook/CacheLib#494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot pushed a commit to facebookexperimental/moxygen that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged
8a35fe9 
Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

X-link: facebook/CacheLib#494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
meta-codesync Bot pushed a commit to facebook/proxygen that referenced this pull request Sep 17, 2026
@michel-slm @meta-codesync
getdeps: satisfy sparsemap from tsl-sparse-map-devel where packaged
21d076f 
Summary:
Fedora and EPEL package sparse-map as tsl-sparse-map-devel: 0.7.0 on F45 and Rawhide (stable since 2026-09-17), 0.6.2 on F44 and EPEL 9, and an EPEL 10 build is under way. With --allow-system-packages this takes sparsemap out of the set of projects built from source, leaving only the Meta stack (folly, fizz, wangle, mvfst, fbthrift) for a vendored distro build. A plain `[rpms]` section is used, as for libsodium, xxhash and snappy: where the package is not installed (CentOS Stream without EPEL, say) getdeps simply falls back to building sparsemap itself.

The F44 version is older than the 0.7.0 the manifest pins, so the difference was checked rather than assumed: the public API of sparse_map and sparse_set is identical between 0.6.2 and 0.7.0 down to template defaults, the tsl::detail_sparse_hash::sparse_array template cachelib reaches into has the same parameters, and the serialization format is unchanged. 0.7.0's only compatibility change is requiring C++17, irrelevant to cachelib. cachelib locates the headers by path (cmake/FindSparsemap.cmake: find_path tsl/sparse_map.h), which the package satisfies at /usr/include/tsl.

Tested on Fedora 44 with tsl-sparse-map-devel 0.6.2 installed: `getdeps.py --allow-system-packages build --no-tests --src-dir=. cachelib` no longer fetches or builds sparsemap (no Assessing/Building step for it in the log), cachelib configures with SPARSEMAP_INCLUDE_DIRS=/usr/include, SparseMapIndex.cpp compiles against the system header with -Werror on, cachebench links, and the build exits 0 after 58 minutes at two jobs.

Manifest-only follow-up to facebook/CacheLib#488 and facebook/CacheLib#493. RHEL hosts only benefit once facebook/CacheLib#495 (distro_family) lands, since getdeps does not currently recognise RHEL as an rpm distro; the two are independent otherwise.

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

X-link: facebook/CacheLib#494

Reviewed By: likewhatevs

Differential Revision: D120501594

Pulled By: michel-slm

fbshipit-source-id: db5b7ad6514b56984aa3d92a24dbde1614ff1ed4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@bigfootjon bigfootjon bigfootjon approved these changes

Assignees

No one assigned

Labels

CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. Merged

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@michel-slm @bigfootjon