chore(ci) : expand lib targets - #50

Heads up before anything else: I opened #53 yesterday doing a subset of what this does (Debian 12 container for a glibc 2.36 floor, release workflow only). I didn't check for open PRs first, which was sloppy of me. This one is older, goes lower (2.28), and covers CI and the smoke test too, so it supersedes mine. Happy to close #53 if this lands. They also touch the same lines in release.yml, so they can't both go in as-is.

Separately, this is showing as conflicting against main and hasn't been updated since early July, so it needs a rebase either way.

The glibc work itself is the right idea and I want it. Most of what's below is about the other four things that came along with it.

Things I'd want changed before merging

Pin the container images. quay.io/pypa/manylinux_2_28_x86_64 with no tag means latest, and pypa rebuilds those regularly. In CI that's mildly annoying. In release.yml it means the binaries we publish aren't reproducible, and an upstream image push can break a release with no change on our side. What's odd is that clang is pinned to 20.1.8.0 exactly, so the toolchain is nailed down but the image handing it to us isn't. A digest pin would settle it.

Why C++20? I went through lance.hpp and it includes <array> <cstdint> <memory> <optional> <stdexcept> <string> <utility> <vector>, with no concepts, ranges, <format>, <span>, coroutines, or <=> anywhere. As far as I can tell nothing in the public headers needs it. Meanwhile CMAKE_CXX_STANDARD 20 plus the bumps to the consumer example, the Conan test_package, and compile_and_run_test.rs push C++20 onto everyone downstream.

That sits awkwardly against the rest of the PR: we widen the glibc floor so more people can consume this, then narrow the language floor so fewer can. There's also a wrinkle specific to manylinux, whose docs note its clang still uses the libgcc/libstdc++ from the image, so the C++20 library surface isn't fully there anyway. If there's a concrete reason I'm missing I'm happy to be talked into it, but right now C++17 looks like it keeps more doors open.

The visibility presets don't do anything. CMAKE_C_VISIBILITY_PRESET, CMAKE_CXX_VISIBILITY_PRESET and CMAKE_VISIBILITY_INLINES_HIDDEN only apply to targets CMake compiles. liblance_c comes out of cargo via Corrosion, and everything else here is INTERFACE or IMPORTED, so no target in the project is affected. It reads like symbol hardening but changes nothing in the shipped library. If hiding symbols is the actual goal it has to happen on the Rust side.

Two with: blocks quietly disappear from release.yml: target: on setup-rust-toolchain and key: on rust-cache, neither mentioned in the description. The target one is probably harmless since every runner is native for its triple. The cache key I'm less sure about: both Linux rows are runner.os == Linux under the same job id, and I think rust-cache disambiguates on the rustc host triple, but I haven't verified that. Putting the key back costs nothing and removes the question.

Smaller things

.github/baseline.env is now a hard build dependency. baseline.cmake raises FATAL_ERROR if it's missing, on every platform, for a value only macOS uses. I checked and this won't break packaging today: both vcpkg_from_github and Conan's get() pull the GitHub source tarball, and there's no .gitattributes export-ignore, so .github/ ships. But a required build input living in a directory everyone reads as "CI stuff" is asking for someone to prune it later. cmake/baseline.env would say what it means. I'd also make the missing-file case non-fatal off macOS.

Related: that file now has two parsers with different rules. CI does set -a; source, CMake does a hand-rolled regex. Shell handles export FOO=bar, quoted values, ${VAR}, and trailing comments. The CMake side handles none of them. Write MACOSX_DEPLOYMENT_TARGET="11" and shell gives you 11 while CMake gives you "11", quotes included. That's a silent divergence in the one value the file exists to keep in sync. Either document the accepted format in the file itself, or generate one side from the other.

The protoc install block is copy-pasted six times (four jobs in ci.yml, plus the smoke test and release). A composite action under .github/actions/ would make the next version bump a one-line change.

Deleting the roadmap feels like its own PR. It's 50 lines of README in a change titled "expand lib targets", and #46 and #48 exist purely to tick boxes in it, so somebody clearly cares about keeping it current. Could it go in a collapsed <details> block instead of away entirely?

We now advertise "GLIBC baseline 2.28" in the README with nothing in CI checking it, so the first regression shows up on a user's machine rather than in a build. I had a go at this on my branch (readelf --dyn-syms on the .so, nm --undefined-only on the .a, take the highest GLIBC_ version, fail if it's above the floor) and can hand it over if it's useful.

Minor, but the rustfmt and license-header jobs now pull a multi-gigabyte manylinux image to run cargo fmt and a grep loop. Neither produces a binary, so that's pure wall-clock cost.

A few nits:

• the arch case has no default branch, so an unexpected uname -m leaves PA empty and you get a 404 on protoc-25.3-.zip instead of a useful error
• the protoc zip isn't checksummed, which is a little inconsistent given how precisely clang is pinned
• manylinux-install-clang is marked BETA upstream, worth knowing we're leaning on it
• the Install Clang 20 (Linux) body is indented 12 spaces where its siblings use 10

Things I liked

The shasum/sha256sum fallback is a good catch. macOS has no sha256sum and manylinux has no shasum, so you genuinely need both arms and it's the kind of thing that only bites you at release time. Pinning protoc instead of taking whatever the distro ships is worth having on its own. timeout-minutes on publish closes a real gap. And keeping the deployment target in one place so CMake and CI can't drift is the right instinct, even if I'd move the file.

❌ Gate recommendation: request changes.

The manylinux direction fixes the demonstrated root cause: the existing v0.1.2 Linux artifact reaches GLIBC_2.39. The remaining blockers share two release contracts: shipped artifacts must prove their advertised runtime floors, and executable inputs to a write-capable release job must be immutable and integrity-checked.

A viable revision would use digest-pinned build roots, restrict the build job to read-only repository access, verify downloaded tools, and gate upload on Linux/Mach-O artifact plus packaged static/shared consumer checks.

Please mark this PR with the breaking-change label.

❌ Gate recommendation: request changes.

2 findings remain / 4 new.

Manylinux 2.28 remains a useful way to lower the Linux ABI floor, but the merge now breaks release-matrix execution. Preserve the existing runner/platform metadata and separate setup by container family, keeping the Debian 12 packages introduced by #53 and the macOS paths working alongside manylinux.

The earlier release supply-chain requirements also remain: pin the manylinux builders, integrity-check the new Linux protoc downloads, and reserve repository write permission for publishing. The previous request for additional compatibility auditing remains withdrawn as a merge prerequisite.

❌ Gate recommendation: request changes.

6 findings remain / 1 new.

The baseline decision settles glibc 2.28 for future generic Linux x86_64/AArch64 packages alongside Debian 12 variants and C++17 consumers; historical release assets are unchanged. #103 records scoped native feasibility, not acceptance of this PR’s workflow.

The recommendation is unchanged: restore consistent matrix metadata and separate Debian/manylinux setup, retaining the macOS release paths. Make the manylinux install physically use lib/ so staging and package consumers agree; the accepted experiments explicitly selected that layout.

The release supply-chain boundary also remains: pin the builders, verify Linux protoc archives, and reserve repository write permission for publishing. Reuse candidate evidence where build inputs match; the earlier blanket compatibility-audit request remains withdrawn.