The build system does not specify minimum required versions of any dependency 😞

[hartwork]

Hi!

Git main fails to compile against the version of Abseil in Debian sid (20240722.0) and users only learn that halfway into the compilation process, when CMake could have made that easy to understand and save users and package maintainers debugging time. I found…

# git grep -h -i '^ *find_package(' | grep -vi '(protobuf' | sort | sed 's,^ *,,'
find_package(absl CONFIG)
find_package(absl CONFIG)
find_package(absl REQUIRED CONFIG)
find_package(gRPC CONFIG REQUIRED)
find_package(GTest CONFIG)
find_package(GTest REQUIRED)
find_package(jsoncpp)
find_package(Threads REQUIRED)
find_package(ZLIB)

…that none of the dependency declarations come with a minimum supported version. Please start requiring the versions of Abseil, gRPC, GTest, jsoncpp and zlib that are needed to successfully compile à la find_package(absl 20250512.1 REQUIRED CONFIG) or so, whatever the actual needed version is. Thank you!

Best, Sebastian

[bellspice]

We would accept a PR for this.

[hartwork]

We would accept a PR for this.

@bellspice three related thoughts:

• We'd need to find and/or agree on versions to put into it and/or clarify requirements of these versions: e.g. there is range from putting some recent version in that works (and to increase precision over time) versus determining the precise current minimum version from the start e.g. through bisection, which takes significantly more time and effort.
• The CI here is very unfriendly to external contributors.
• I have an open (unrelated) pull request CMake: Stop building tests by default (related to #20539) #24373 that has not yet been reviewed. I would ask for some review there before offering more pull requests.

[hartwork]

Update: I learned that vanilla Abseil 20240722.0 is the oldest version that Protobuf main compiles with. The fact that that version does not work in Debian is apparently from downstream patching in Debian. I created PR #24398 just for the Abseil version now and will likely create another issue with details on the issue from Debian (as it may point out an upstream bug). EDIT: Done with #24399.

[mkruskal-google]

To clarify a bit, it's not clear to us how well CMake supports this kind of thing. My understanding was that version identifiers were just opaque strings to CMake, so it wouldn't have a good way to compare them against a known minimum. If it's possible to do this, I think a PR demonstrating how to do it would be a good starting point and we could do the work of finding out what actual minimums we want.

We like the idea, but our cmake configs aren't a very high priority

[hartwork]

@mkruskal-google CMake does version comparison between what it finds and what the users asks for, and the dependency has full control over the decision whether they consider themselves compatible to the version asked for. There are four modes…

• a) AnyNewerVersion — optimistic
• b) SameMajorVersion — regular SemVer
• c) SameMinorVersion — pessimistic SemVer
• d) ExactVersion — super pessimistic, exact pinning

…offered by CMake utility function write_basic_package_version_file that CMake-based projects can use to communicate their wishes to future reverse dependencies, and it produces file content like this, case SameMajorVersion there.

Abseil may be putting its users in trouble through https://github.com/abseil/abseil-cpp/blob/e6a6acdca4e43f75a5f44a9a2ea74385a2f568c2/CMakeLists.txt#L204-L207 and effectively break >= detection as envisioned in #24398 — it needs re-checking then.

What do you think?

[mkruskal-google]

IIRC that Abseil code you're pointing to is modified during their release process. So it would break the detection against unreleased versions of Abseil, but we could have a disable flag for that case probably.

I think this is a good idea in general. We get a lot of issues from people hitting confusing build failures due to incompatible versions of dependencies. Advertising our minimum support would help clarify things