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…
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)
- Allow community to provide several abseil package “flavor” which can be installed alongside like
- 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
BTW I’m open to any suggestion/discussion concerning this incoming issue…
ps: first post here don’t hesitate to edit/move it