Abseil and C++ revision


Currently homebrew/homebrew-core provide an abseil.rb package compiled against the c++11 revision AFAIK.

Abseil-cpp has the particularity to change its behavior according to the C++ revision used.
e.g. if using c++17 most abseil-cpp becomes just alias to the STL while in c++11 it is a custom code.
Thus libraries depending on abseil-cpp must use the same C++ revision than the one use to compile abseil-cpp ! (yes it’s a very FOSS package maintainer unfriendly feature…)

I was on the process to provide a formula for the project I’m maintaining, google/or-tools, for the Homebrew community…
see: https://github.com/Mizux/homebrew-or-tools

Since Google LLC is already moving to C++17, so the project I maintain, google/or-tools, is now compiled against c++17 (on master) and is already using few C++17 features thus we are using abseil-cpp compiled against c++17…
Without being a bird of bad omen, we can expect in the near future that other projects depending on abseil-cpp will also use a C++ revision different from the actual c++11.

So, as expected, currently I can’t build or-tools against system-wide dependencies (i.e. homebrew abseil package)

My proposal:

  1. Allow community to provide several abseil package “flavor” which can be installed alongside like
    abseil_c++11 and abseil_c++17 etc…
  2. See how in formula we can manage to find the “correct” install (e.g. using CMAKE_PREFIX_PATH to help CMake to find the “correct” one during its find_package() search procedure)

BTW I’m open to any suggestion/discussion concerning this incoming issue…

ps: first post here don’t hesitate to edit/move it

My suggestion would be to see if you can get all formula that depend on it to use the c++17 version.

@SMillerDev is it possible to get the reverse dependencies of abseil.rb i.e. who is using it ?

brew uses --recursive --include-build --include-test abseil

1 Like

since the beginning of this topic there is now the Formula
grpc which is directly using abseil.

I’ve fixed grpc in PR #62916