dep provider: fixes#476
Conversation
|
|
@jcar87 - Any idea of solving the CAE problem mentioned in #475 (comment)? |
| endif() | ||
|
|
||
| string(APPEND PROFILE "[conf]\n") | ||
| string(APPEND PROFILE "tools.cmake.cmaketoolchain:generator=${CMAKE_GENERATOR}\n") |
There was a problem hiding this comment.
Is CMAKE_GENERATOR always defined as a variable? Even when not provided in CLI and defaulted?
There was a problem hiding this comment.
yup, should be defined by CMake itself, even when not provided by the user
| message(STATUS "CMake-conan: first find_package() found, running 'conan install' to install deps") | ||
| detect_host_profile(${CMAKE_BINARY_DIR}/conan_host_profile) | ||
| if(CMAKE_BUILD_TYPE) | ||
| if(NOT CMAKE_CONFIGURATION_TYPES) |
There was a problem hiding this comment.
I was relying on the fact that users in Windows can still force installing just 1 configuration with -DCMAKE_BUILD_TYPE=Debug, even if that does nothing, Conan will know to install only the Debug.
If we are not allowing this, we would need another kind of opt-out I guess?
There was a problem hiding this comment.
yup, we would need some opt-out indeed! I would try to avoid giving CMAKE_BUILD_TYPE a meaning in the context of a multi-config generator (where giving CMAKE_BUILD_TYPE a value at configure time is unfortunately allowed, but will have no effect).
4 participants
tools.cmake.cmaketoolchain:generator- this will cause the CMakeDeps generator to generate files in the same folder when callingconan installfor both Debug and Releaseconan installtwice based onCMAKE_CONFIGURATION_TYPES- this is only defined in multi-config generators - unfortunatelyCMAKE_BUILD_TYPEmay still be defined at configure time even on a multi-config generator (even if it is a no-op)The test passes on Linux and Mac now. On Linux it passes with both gcc and clang.