#69578 closed enhancement (fixed)
abseil @ 20240116.1: Update cxx_standard to 2017
Reported by: | FlyingSamson | Owned by: | judaew (Vadym-Valdis Yudaiev) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.9.1 |
Keywords: | Cc: | FlyingSamson | |
Port: | abseil |
Description
I'm currently trying to package or-tools in macports (as a dependency to yet another package flatcam).
The current version of or-tools (and the only one compatible with abseil 20240116) requires that absl::string_view
can be assigned to a std::string
, which in turn according to the standard requires that absl::string_view
can be converted to std::string_view
. However, as std::string_view
is a c++17 feature, this would require an abseil version compiled with -std=c++17
.
So my question is, wether it would be reasonable to update the standard used for building abseil from the current c++14 to c++17?
Of course I realize that there are quite some ports depending on abseil and would be happy to help in testing if these still build with such an updated version of abseil if that is of any help.
Change History (6)
comment:1 Changed 8 months ago by FlyingSamson
Cc: | FlyingSamson added |
---|
comment:2 Changed 8 months ago by ryandesign (Ryan Carsten Schmidt)
Cc: | judaew@… removed |
---|---|
Owner: | set to judaew |
Status: | new → assigned |
comment:3 Changed 8 months ago by FlyingSamson
Yes, I fear abseil itself is required to be compiled with c++17 standard. Because if it is compiled with c++14 standard, it declares its own implementation of absl::string_view
which cannot provide an implicit conversion to std::string_view
as this type only exists since c++17. Then compiling or-tool will fail as an assignment of abseil's own absl::string_view
to an std::string
is not possible.
If you would rather not update abseil to c++17 yet, I could also try patching or-tools to assign the contents of the absl::string_views
to the std::string
variable (replicating the standard's implementation of std::string::operator=(std::string_view)
, but I fear that would result in a quite large patch set. Therefor, I thought I ask first if it would be acceptable to update the c++ standard used to compile abseil, instead.
comment:4 Changed 7 months ago by judaew (Vadym-Valdis Yudaiev)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:5 Changed 7 months ago by FlyingSamson
Thanks for updating the port.
Unfortunately, the change only restricts the used compiler, but does not actually cause the code to be build with c++17 standard enabled.
This would require to additionally switch the line -DCMAKE_CXX_STANDARD=14
to -DCMAKE_CXX_STANDARD=17
(line 71 in the updated portfile).
If abseil already requires C++14 (which requires Apple clang 602 or later according to CompilerSelection) then bumping that to C++17 (which requires Apple clang 1000 or later) is not such a big difference, especially considering that abseil additionally already requires Apple clang 900 or greater for some other reason per #67553.
Just to make sure though: abseil must be compiled with C++17? It is not sufficient to compile or-tools with C++17 when abseil had been compiled with C++14?