This works because there is only one configuration specified. One option might be to generate variable names based on the options passed (maybe this is what you meant already). Using this CMake functionality in combination with Conan is currently not practically possible, which is a shame. CMake has been set up specifically to allow setting these debug and release options in a single CMake project. However, with regard to Visual Studio workflows, having a working debug and release switch is a convenient thing to have. Your point is definitely a good one, doing this generically is a challenge. It even makes more sense if using the visual_studio generator, as you can load a diferent conanbuildinfo.vsprops for each project configuration. I think this approach doesn't scale for a generic use case, while the folder one, every one can set their own "builds", and including the selecting logic in the main CMakeLists.txt to select the appropriate conanbuildinfo.cmake is very straightforward. What should be done if the user requests -s build_type=Debug Release DebugWithRelInfo -s arch=x86 x86_64 armv6? Should the conanbuildinfocmake contain all the possible combinations? Why wouldn't it be applied for compiler versions? Do we want a cmake variable named CONAN_INCLUDE_DIRS_X86_DEBUG_VISUAL_14? I am not opposed to implement this feature request, but would also like to keep the conan codebase as terse as possible. The reason is that this approach is generic, work always, for multi and single configuration. Many times this task is also automated with a small script.
Cmake debug unoptimized windows#
(This feature is of particular interest for Windows projects in which debug libraries using the C++ standard library cannot be mixed with release build of the executable and vice versa (i.e.
Cmake debug unoptimized install#
For instance by doing 'conan install -s build_type=Debug Release' would retrieve both the debug and release versions of the packages and the cmake generator would create corresponding CMake library variables containing 'debug' and 'optimized' statements. It would be convenient to be allowed to specify a multi-configuration project in Conan. Where by specifying either 'debug' or 'optimized' in front of the library name CMake is able to generate a Visual Studio project with both a debug and optimized configuration. However, CMake (mostly in combination with Visual Studio projects) supports multi-configuration projects.
When no build type is specified 'release' is assumed. release or debug) at the moment of calling 'conan install'.
Currently Conan requires explicitly specifying the build type (i.e.
0 kommentar(er)
