CMake Targets

[OlafvdSpek]

Here's a non-exhaustive list of Abseil CMake public targets:

Could the list be completed?

https://github.com/abseil/abseil-cpp/tree/master/CMake

[OlafvdSpek]

set(CMAKE_CXX_FLAGS "-std=c++11 -stdlib=libc++ ${CMAKE_CXX_FLAGS}")

AFAIK that's not the proper way to select c++11.

[JonathanDCohen]

Hey there! Thanks for the comments.

We will definitely update the readme. I just got back from vacation and am triaging all the CMake related issues and once they're all together I'll update all the information.

The correct way to set the language level for abseil is to set CMAKE_CXX_STANDARD to 11, 14, or 17. We use it here and then here and here.

[OlafvdSpek]

Is it OK if Abseil is build with 11 and the program itself is build with 17?

[mbxx]

I haven't tried it, but that's extremely likely to go badly because the underlying types for absl::string_view are different in C++11 and C++17 compilation modes (https://github.com/abseil/abseil-cpp/blob/master/absl/strings/string_view.h#L33).

Can you give us a little more background on why you'd like to compile Abseil as C++11 if the rest of your program is C++17? This isn't something we've heard of people wanting to do before. If we understand the problem better, we may be able to offer alternatives or work on a fix if the problem is on our end.

[OlafvdSpek]

It's actually related to #260

If it's a bad idea and the compiler defaults to C++14 (GCC 6) and Abseil defaults to C++11 then something is wrong.

[JonathanDCohen]

Abseil uses the value of CMAKE_CXX_STANDARD since this is the cmake way of controlling C++ language level for all targets. How are you specifying C++17 in your build?

[OlafvdSpek]

set(CMAKE_CXX_FLAGS -std=c++17) which is wrong. ;)
But what if c++17 became the default in a future GCC, like c++14 already is? CMAKE_CXX_STANDARD might not be set in that case.

[mbxx]

Abseil supports compilers for 5 years, which includes a lot of versions of GCC for which C++14 is not the default. If Abseil changed the default C++ version, then users of those old but supported GCC versions who rely on the default would have their builds break when they pull in the latest version of Abseil.

I don't think there's a good answer here. It's really important that users specify what version of C++ they're using. I can see an argument that not specifying a version should be an error instead of a warning, though.

[MikeGitb]

The correct way to set the language level for abseil is to set CMAKE_CXX_STANDARD to 11, 14, or 17.

If I may make a comment on this: In my experience this is the absolutely wrong approach for a library. Especially if your API changes depending on the language level, then the used standard is something that you should simply adopt from the project abseil is used from.

Otherwise there are two possibilities:

• Either the library and the application happen to use the same c++ version and doing a set CMAKE_CXX_STANDARD in the library cmake file is redundant,
• or both are using a different version and everything is blowing up in your face.

set CMAKE_CXX_STANDARD belongs either in the top level cmake file of the Application (if the libraries are added via add_subdirectory( ... ) ) or even better in the toolchain file that is used to build all the applications and libraries or (e.g. for testing and ci) in the command line command that invokes cmake( cmake -DCMAKE_CXX_STANDARD=17 ..).

The only thing a library cmake file should do is a target_compile_features(mylib PUBLIC cxx_std_11) to state the minimum language version it needs.

[JonathanDCohen]

If I may make a comment on this: In my experience this is the absolutely wrong approach for a library. Especially if your API changes depending on the language level, then the used standard is something that you should simply adopt from the project abseil is used from.

How do you propose to do this besides the standard mechanism in CMake?

Otherwise there are two possibilities:

Either the library and the application happen to use the same c++ version and doing a set CMAKE_CXX_STANDARD in the library cmake file is redundant,
or both are using a different version and everything is blowing up in your face.
set CMAKE_CXX_STANDARD belongs either in the top level cmake file of the Application (if the libraries are added via add_subdirectory( ... ) ) or even better in the toolchain file that is used to build all the applications and libraries or (e.g. for testing and ci) in the command line command that invokes cmake( cmake -DCMAKE_CXX_STANDARD=17 ..).

We don't set CMAKE_CXX_STANDARD, we only read it. The relvant code is here In fact our test scripts do what you suggested, using -DCMAKE_CXX_STANDARD in the command line.

The only thing a library cmake file should do is a target_compile_features(mylib PUBLIC cxx_std_11) to state the minimum language version it needs.

But this is a problem in a library like abseil which changes depending on language level. We need to know what language level our dependents are using, and so we must use the tool given to us in CMake to detect C++ language level.

[OlafvdSpek]

We don't set CMAKE_CXX_STANDARD, we only read it.

That might not be right. If it's unset, you default to C++11 which might not be what the compiler defaults to.

[MikeGitb]

@JonathanDCohen: Sorry, my mistake. I read this as "the correct way is for abseil to use set(CMAKE_CXX_STANDARD". I shouldn't post when I'm tired.
My broader point stands though: you should not set an explicit cmake standard for individual targets./libraries

How do you propose to do this besides the standard mechanism in CMake?

Just do nothing. If the parent project / toolchain file sets CMAKE_CXX_STANDARD, then your targets will automatically adopt it. If your parent manually adds -std=c++11 to the global CXX flags (it shouldn't but...) your targets will adopt them. And if the parent just uses the compiler default, then so will abseil.

The only thing a library cmake file should do is a target_compile_features(mylib PUBLIC cxx_std_11) to state the minimum language version it needs.

But this is a problem in a library like abseil which changes depending on language level.

cxx_std_11 only sets the minimum required level to 11. If your parent sets CMAKE_CXX_STANDARD to 14 or the compilers default is c++14, abseil will still be compiled with c++14. Also, as a public property, this propagates to your users, so even if they use a compiler that doesn't default to c++11 or later (gcc4.9) and they don't manually set the standard level in one way or another, your users will automatically be compiled with c++11 (EDIT: And we can argue whether that is actually desirable or not).

The only situation, where this unfortunately doesn't work is if another library uses e.g. target_compile_features(mylib PUBLIC cxx_std_17), you are using target_compile_features(abseil PUBLIC cxx_std_11) and all your parent does is target_link_libraries(myexec mylib abseil) (wihtout specifying a global language level). In that case, abseil will be compiled with c++11, but myexec with c++17. Unfortunately, I don't think cmake offers any solution to this problem.

We need to know what language level our dependents are using, and so we must use the tool given to us in CMake to detect C++ language level.

Do you actually have to know this anywhere in the cmake scripts or does it just have to be consistent? The less individual libraries meddle around with compile flags the easier it is to compile everything with a consistent set of flags, because that is what cmake does by default automatically.

[OlafvdSpek]

so even if they use a compiler that doesn't default to c++11 or later (gcc4.9)

IIRC the default has never been C++11. GCC 6 defaults to C++14, before that it was C++03 (or 98).

The only situation, where this unfortunately doesn't work is if another library uses e.g. target_compile_features(mylib PUBLIC cxx_std_17), you are using target_compile_features(abseil PUBLIC cxx_std_11) and all your parent does is target_link_libraries(myexec mylib abseil) (wihtout specifying a global language level). In that case, abseil will be compiled with c++11, but myexec with c++17. Unfortunately, I don't think cmake offers any solution to this problem.

Won't the requirement of mylib bubble up and cause everything to use C++17?