Wrong setting for 'settings.compiler.libcxx' detected for gtest/1.8.1@bincrafters/stable

[lorenzzhao]

When trying to add dependency to gtest:

conan_cmake_run(
    REQUIRES
    gtest/1.8.1@bincrafters/stable
    BASIC_SETUP
    )

on call of

cmake .. -DCMAKE_BUILD_TYPE=Debug

I get:

-- Conan: Adjusting output directories
-- Conan: Using cmake global configuration
-- Conan: Adjusting default RPATHs Conan policies
-- Conan: Adjusting language standard
-- Current conanbuildinfo.cmake directory: /home/.../build-test-Debug
-- Conan: Compiler GCC>=5, checking major version 5
-- Conan: Checking correct version: 5
-- Conan: C++ stdlib: libstdc++
-- Conan: Automatic detection of conan settings from cmake
c++: error: $<$<CONFIG:Debug>:>: No such file or directory
c++: error: $<$<CONFIG:Release>:>: No such file or directory
c++: error: $<$<CONFIG:RelWithDebInfo>:>: No such file or directory
c++: error: $<$<CONFIG:MinSizeRel>:>: No such file or directory
-- Conan: Settings= -s;build_type=Debug;-s;compiler=gcc;-s;compiler.version=5;-s;compiler.libcxx=libc++
-- Conan executing: conan install . -s build_type=Debug -s compiler=gcc -s compiler.version=5 -s compiler.libcxx=libc++ -g=cmake
-- ERROR: Invalid setting 'libc++' is not a valid 'settings.compiler.libcxx' value.
Possible values are ['libstdc++', 'libstdc++11']
Read "http://docs.conan.io/en/latest/faq/troubleshooting.html#error-invalid-setting"

CMake Error at /home/.../cmake/conan.cmake:385 (message):
  Conan install failed='1'
Call Stack (most recent call first):
  /home/.../cmake/conan.cmake:465 (conan_cmake_install)
  /home/.../CMakeLists.txt:12 (conan_cmake_run)

Working on Ubuntu 16.04 LTS with default GCC (5.4.0).

[Croydon]

Please have a look in your settings.yml file. It looks like only ['libstdc++', 'libstdc++11'] would be the possible values in there for settings.compiler.libcxx

You need to add libc++ if you want to use it

[memsharded]

It would also be important to know if using libc++ is the intended one. @lorenzzhao do you have something in your CMakeLists.txt that defines this stdlib? Otherwise it would be a bug in cmake-conan, and we would need to reproduce why in your case it believes that it needs to use the clang libc++ stdlib. Please feedback, thanks!

[theovin]

When building one of our projects - where the build worked (!) recently - we stumbled upon the same problem on Ubuntu 16.04 LTS both with GCC 7.4.0 as well as GCC 5.4.0. The build is executed during creation of a docker image - therefore it is a "clean" system we are starting from:

-- Conan: Automatic detection of conan settings from cmake
-- Conan: Settings= -s;build_type=Release;-s;compiler=gcc;-s;compiler.version=7;-s;compiler.libcxx=libstdc++11
-- Conan executing: conan install . -s build_type=Release -s compiler=gcc -s compiler.version=7 -s compiler.libcxx=libstdc++11 -g=cmake --build=outdated
-- Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=7
os=Linux
os_build=Linux
[options]
[build_requires]
[env]

... etc. ...

conanfile.txt: Generator cmake created conanbuildinfo.cmake
conanfile.txt: Generator txt created conanbuildinfo.txt
conanfile.txt: Generated conaninfo.txt
conanfile.txt: Generated graphinfo

-- Conan: Loading conanbuildinfo.cmake
-- Current conanbuildinfo.cmake directory: /root/workspace/sw/build/temp
-- Conan: Compiler GCC>=5, checking major version 7
-- Conan: Checking correct version: 7
-- Conan: Using cmake global configuration
-- Conan: Adjusting default RPATHs Conan policies
-- Conan: Adjusting language standard
-- Conan: Automatic detection of conan settings from cmake
c++: error: $<$<CONFIG:Debug>:>: No such file or directory
c++: error: $<$<CONFIG:Release>:>: No such file or directory
c++: error: $<$<CONFIG:RelWithDebInfo>:>: No such file or directory
c++: error: $<$<CONFIG:MinSizeRel>:>: No such file or directory
-- Conan: Settings= -s;build_type=Release;-s;compiler=gcc;-s;compiler.version=7;-s;compiler.libcxx=libc++
-- Conan executing: conan install . -s build_type=Release -s compiler=gcc -s compiler.version=7 -s compiler.libcxx=libc++ -g=cmake --build=outdated
-- ERROR: Invalid setting 'libc++' is not a valid 'settings.compiler.libcxx' value.
Possible values are ['libstdc++', 'libstdc++11']
Read "http://docs.conan.io/en/latest/faq/troubleshooting.html#error-invalid-setting"

CMake Error at conan.cmake:385 (message):
  Conan install failed='1'
Call Stack (most recent call first):
  conan.cmake:465 (conan_cmake_install)
  CMakeLists.txt:56 (conan_cmake_run)


-- Configuring incomplete, errors occurred!
See also "/root/workspace/sw/build/temp/CMakeFiles/CMakeOutput.log".

Downgrading conan.cmake to v0.13 in our project's CMakeLists.txt helped us to work-around the problem for the moment...

file(DOWNLOAD "https://raw.githubusercontent.com/conan-io/cmake-conan/v0.13/conan.cmake" "${CMAKE_CURRENT_LIST_DIR}/conan.cmake")

...so it seems to us, that the new version of conan.cmake causes the problem.

[lorenzzhao]

Sorry for the delay...

I tried to reproduce the problem today to provide some more information on the scenario, but I didn't manage to get the error again. So works fine for me now.

Sorry for the inconvenience.

If @theovin has more information on his scenario, please consider to reopen the bug.

[verbatom]

I debugged conan.cmake 0.14 and identified the cause of the error:

It is located inside the conan_cmake_detect_unix_libcxx function and starts with the execution of get_directory_property(compile_options DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} COMPILE_OPTIONS)

This call assigns a string to compile_options ending with [...];$<$<CONFIG:Debug>:>;$<$<CONFIG:Release>:>;$<$<CONFIG:RelWithDebInfo>:>;$<$<CONFIG:MinSizeRel>:>

The subsequent execution attempt of the C++ compiler with these compiler options execute_process( [...] COMMAND ${CMAKE_CXX_COMPILER} -x c++ ${compile_options} [...] ) fails due to the empty CMake generator expressions such as $<$<CONFIG:Debug>:> (notice the colon being immediately follow by a closing angular bracket :>).

When deleting the empty generator expressions substring before the execution of the C++ compiler, CMake executes just fine.

string(REPLACE ";\$<\$<CONFIG:Debug>:>;\$<\$<CONFIG:Release>:>;\$<\$<CONFIG:RelWithDebInfo>:>;\$<\$<CONFIG:MinSizeRel>:>" "" compile_options "${compile_options}")

(This replacement is only for demonstration purposes as the order and number of expressions may vary depending on the specific setup.)

@lorenzzhao Could you please re-open this issue as I do not have the rights to do that?

[lorenzzhao]

According to @verbatom there actually is a bug, so I reopen the issue as requested.

[daedric]

I also have the problem, it seems to be triggered when I "add_subdirectory" some other cmake project which uses Conan.

I've added a string(GENEX_STRIP "${compile_options} compile_options) where you indicated and apart from a warning on the build type not detected and being defaulted to Release for one of the deps it worked.

[verbatom]

Thank you for your bug report! It seems that the specific setup required to reproduce this error is not very common amongst the users of Conan CMake, as you are one of a few reporting this problem.

[...] seems to be triggered when I "add_subdirectory" some other cmake project which uses Conan [...]

Since I am not sure which part of my setup leads to the error, I have tried omitting the add_subdirectory command in my CMake project and was still getting the same error message. This project depends on libs (part of Conan package) which in turn is composed of multiple other libs (Conan packages).

@daedric: Does your setup also include nested (Conan package) dependencies in the following or a simpler form?

+------------------+          +-----------+          +-----------+
| executable CMake |          |           |          |           |
| project using    |--------->| package A |--------->| package B |
| conan.cmake      |          |           |          |           |
+------------------+          +-----------+          +-----------+
         |                                                 ^
         +-------------------------------------------------+

[daedric]

I've something more similar to this:

+------------------+                  +------------------+          +-----------+
| executable CMake | add_subirectory  | library in sub   |          |           |
| project using    |----------------> | project using    |--------->| package A |
| conan.cmake      |                  | conan.cmake      |          |           |
+------------------+                  +------------------+          +-----------+
         |                                                               ^
         +---------------------------------------------------------------+

[davnat]

I was having the very same issue reported by @theovin I double-checked my CmakeLists.txt and found that

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()

was executed before

conan_cmake_run(REQUIRES "Catch2/2.7.2@catchorg/stable"
                BASIC_SETUP
                BUILD missing)

(this is a header-only C++ library that requires Catch2 when building tests)

Making sure conan_basic_setup() is skipped when conan_cmake_run() is called resolved my issue.

Hope this helps, cheers

[Malacath-92]

This is still an issue right now for me: https://travis-ci.org/Malacath-92/dla/jobs/659319450 It only seems to happen when building with gcc, not with clang (I assume that's because libc++ is a valid setting in that case) I don't add_subdirectory() another project using conan.cmake. I don't run conan_basic_setup() manually. I don't mention libc++ anywhere in my CMakeLists.txt So none of the suggestions here help me.

@verbatom Have you ever investigated your suggestion closer?

Edit: My bad, this issue refers to gtest, my issue seems to happen on my root project.

[verbatom]

@Malacath-92: All observations and findings are listed in this issue including links to a duplicate and a pull request from October 2019 scheduled for milestone 0.16 to which is still open.

As mentioned in the answers of this issue, your current possibilities for dealing with the problem are the following:

1. revert to v0.13 until a fixed release version is available
2. locally patch your version of the file

[...] My bad, this issue refers to gtest [...]

At least @theovin and I also referred to different projects in our bug reports instead of opening a new issue as the trigger for the problem might be different but the origin seemd to be the same.

[Yuri6037]

Any advancement on this issue? This prevents the build of cross platform projects and v0.14 minimum is required to support MSVC 2019.

[Yuri6037]

I ended up like just cloning the code in my own repository and adding additional code to fit my needs and I also applied the patch for the tool to work on all systems without having any manual steps...