Comments (6)
Hello, has there be any further progress on this? When using conan.cmake I'd like to copy all the debug runtime dlls into the debug directory, and the release dlls into the release build directory (note this isn't at the install step, but more for convenient build and run debugging). The first try at this was to use a conanfile.py but I'd like to have dynamic requirements depending on cmake flags, and I didn't want to touch the existing conan.cmake file in case it changes in the future.
I've written a macro which gets a similar effect to what I was after, but it'd be nice to have a formal function for this. Here's the macro - I don't think it handles the settings correctly, but it seems to work in the basic case. It also doesn't handle the case of putting dylibs/so into the rights spot either.
macro(GenerateDebugImports)
set ( CONANDEBUGIMPORTS
"bin, *.dll -> ./DebugImports"
"lib, *.dylib -> ./DebugImports"
"lib, *.so -> ./DebugImports"
)
conan_cmake_setup_conanfile(REQUIRES ${CONANREQUIREMENTS} IMPORTS ${CONANDEBUGIMPORTS})
conan_cmake_settings(settings)
conan_cmake_install(SETTINGS ${settings})
endmacro()
macro(GenerateReleaseImports)
set ( CONANRELEASEIMPORTS
"bin, *.dll -> ./ReleaseImports"
"lib, *.dylib -> ./ReleaseImports"
"lib, *.so -> ./ReleaseImports"
)
conan_cmake_setup_conanfile(REQUIRES ${CONANREQUIREMENTS} IMPORTS ${CONANRELEASEIMPORTS})
conan_cmake_settings(settings)
conan_cmake_install(SETTINGS ${settings})
endmacro()
if(CMAKE_BUILD_TYPE STREQUAL "Debug")
GenerateDebugImports()
elseif(CMAKE_BUILD_TYPE)
GenerateReleaseImports()
else()
foreach(CMAKE_BUILD_TYPE "Release" "Debug")
if(CMAKE_BUILD_TYPE STREQUAL "Debug")
GenerateDebugImports()
else()
GenerateReleaseImports()
endif()
endforeach()
set(CMAKE_BUILD_TYPE)
endif()
< Other Library Setup Code goes here, including the conan call. The conan call has to go after the above, because otherwise we don't create a valid conanbuildinfo_multi.cmake file. >
conan_cmake_run(REQUIRES ${CONANREQUIREMENTS}
BASIC_SETUP CMAKE_TARGETS NO_OUTPUT_DIRS
BUILD missing)
<other code>
add_custom_command(
TARGET TestTarget POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_directory "./$<$<CONFIG:Debug>:Debug>$<$<NOT:$<CONFIG:Debug>>:Release>Imports" "$<TARGET_FILE_DIR:TestTarget>"
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
Also there's a bug with the current implementation if you just try and set CMAKE_BUILD_TYPE with the visual studio compiler as an argument to conan_cmake_run - it will do the right thing in conan_cmake_settings i.e.:
if(ARGUMENTS_BUILD_TYPE)
set(_SETTINGS ${_SETTINGS} -s build_type=${ARGUMENTS_BUILD_TYPE})
elseif(CMAKE_BUILD_TYPE)
set(_SETTINGS ${_SETTINGS} -s build_type=${CMAKE_BUILD_TYPE})
however in the visual studio runtime detection, it fails here because it doesn't check for the argument version and falls back to the direct cmake variable:
function(conan_cmake_detect_vs_runtime result)
string(TOUPPER ${CMAKE_BUILD_TYPE} build_type)
Which causes it to use the release runtime (MD) when you're building in debug mode and compilation fails.
from cmake-conan.
I have added the definition of the CONAN_IMPORT_PATH as environment variable from the conan.cmake in 36f25ff.
It is in develop branch (the main branch of https://github.com/conan-io/cmake-conan), so if you could please check from there that it behaves like you want, it would be useful, to be sure before it is released. Thanks!
from cmake-conan.
So my particular use case is the following:
We have a set of dependencies for our main application as follows:
set ( REQUIREDDEPS
dep1/master@user/stable
dep2/master@user/stable
)
However we also have some dependencies which we enable by cmake configuration flags:
Something like:
option(USE_TBB "Uses the Intel TBB malloc library for fast memory allocation" ON)
if (USE_TBB)
set (TBBCONANREQUIRE "TBB/2018_U1@user/stable")
set (TBBEXTERNAL CONAN_PKG::TBB)
endif (USE_TBB)
We then combine these into a REQUIRES for the conan cmake call:
set ( CONANREQUIREMENTS
${REQUIREDDEPS}
${TBBCONANREQUIRE}
)
Now the issue is to bring the dlls into the cmake build directory:
set ( CONANIMPORTS
"bin, *.dll -> ./bin"
"lib, *.dylib -> ./lib"
"lib, *.so -> ./lib"
)
conan_cmake_run(REQUIRES ${CONANREQUIREMENTS}
BASIC_SETUP CMAKE_TARGETS NO_OUTPUT_DIRS
IMPORTS ${CONANIMPORTS}
BUILD missing)
Unfortunately in a multiconfiguration generator such as visual studio, IMPORTS ${CONANIMPORTS}
copies both the debug and release dlls to the same directory because conan_cmake_install() is called subsequently in debug and release mode.
As conan.cmake creates a conanfile.txt, and not a conanfile.py, I can't do something like:
set (CONANIMPORTS
if (settings.build_type == "Debug") {
self.copy("*.dll", src="debug/bin")
} else {
self.copy("*.dll", src="release/bin")
}
)
or:
dest = os.getenv("CONAN_IMPORT_PATH", "bin")
self.copy("*.dll", dst=dest, src="bin")
self.copy("*.dylib*", dst=dest, src="lib")
so unless the .txt format supports the direct substitution of CONAN_IMPORT_PATH (I'm not sure that it does - correct me if I'm wrong but I couldn't find it in the documentation), this will involve creating a premade conanfile.py and passing it in with CONANFILE, however then I lose the ability to dynamically create the REQUIRES depending on the cmake options.
from cmake-conan.
I see. I'd recommend to provide your own conanfile.py, and call it from the cmake providing the CONANFILE parameter. It will probably be cleaner and easier to extend for other cases that the conanfile.txt might be limited. Is there any reason you can't use a conanfile.py?
from cmake-conan.
I'm facing this same issue too. I take it there has been no further progress on this? In my opinion, for a multi-configuration CMake generator (in my case VS) the import instructions need to be translated to an "install" expression for CMake as part of the target definition. The alternative is perhaps that conan performs the import step for every possible configuration (we tend to use exclusively Debug & RelWithDebInfo configurations, but rarely Release). That would be wasteful, but the only way that import can run at CMake configure time?
from cmake-conan.
I don't want to import in the build dir on ELF systems, since the RPATHs are correctly set right into .conan dirs.
We want it to be done on windows, though.
However, in all cases, I want to launch the imports after cmake's install target.
Since the user may have chosen anything as CMAKE_INSTALL_LIBDIR (and BINDIR on windows), it doesn't make sense to have the imports function in conanfile.py use a hardcoded destination dir.
Somehow, I think I don't understand what the imports function goal is, or there's really a missing piece in the puzzle.
I'm balanced between two options:
- investigating the IMPORTED_LOCATION properties of all libraries, since at some point the generated conanbuildinfo.cmake sets them to the actual abs path of the library. Then, do install(PROGRAMS) calls to put them in CMAKE_INSTALL_LIBDIR (or BINDIR for windows)
- hacking conanfile.py so imports gets its destination from an env var. I'd call conan imports at the end of cmake_install.cmake, with that env var set to CMAKE_INSTALL_LIBDIR (or BINDIR for windows).
from cmake-conan.
Related Issues (20)
- [question] Invalid: 'settings.compiler.runtime' value not defined HOT 21
- Different formatting of msvc runtime value conan_provider.cmake
- Installing only certain packages HOT 8
- [develop2] Question: How stable is the current state HOT 2
- tools.build:compiler_executables breaks build with Autotools and Xcode HOT 3
- [develop2] detect_compiler() detects invalid 'settings.compiler.version' for apple-clang
- [develop2] Can conan_provider.cmake work with add_subdirectory HOT 6
- find_program working when building from command line, but not when using the CLion Conan plugin HOT 11
- [bug] generated settings.yml missing Macos.version "14.2", causes build failures HOT 10
- [develop2, BUG] Unknown arguments specified in conan_provider.cmake:519 HOT 2
- Unable to cross compile openssl/3.x.x on develop2 HOT 5
- Using "build-scripts" package via tool_requires() not working HOT 2
- [develop2] CMAKE_CONFIGURATION_TYPES with custom build types not getting dependencies added properly HOT 3
- ERROR: Invalid setting '6' is not a valid 'settings.compiler.version' value HOT 2
- 【conan install】conan_provider.cmake downloads packages from source because detect_host_profile generates compiler.cppstd=xx in the cmake-build-release/conan_host_profile file with the detect_host_profile method HOT 5
- cmake bootstrapping fails if not on PATH HOT 3
- Not working with conan editable mode HOT 5
- Update readme with more details HOT 1
- MSVC version update HOT 6
- [question] Using layout and -of together Conan 2 HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cmake-conan.