Poc/toolchain simpler #7076
Poc/toolchain simpler #7076
Conversation
| set(CMAKE_C_FLAGS_INIT "${CONAN_C_FLAGS}" CACHE STRING "" FORCE) | ||
| set(CMAKE_SHARED_LINKER_FLAGS_INIT "${CONAN_SHARED_LINKER_FLAGS}" CACHE STRING "" FORCE) | ||
| set(CMAKE_EXE_LINKER_FLAGS_INIT "${CONAN_EXE_LINKER_FLAGS}" CACHE STRING "" FORCE) | ||
| """) |
There was a problem hiding this comment.
Would it be an option to inject additionally a current CMake toolchain to the generated one by using include(my_toolchain.cmake)? Or how would one handle the interoperability for example with some well-known toolchains like the one shipped as part of the Android NDK.
There was a problem hiding this comment.
Yes, definitely. This is a very barebones initial proposal, but this would be a necessary feature.
In reality, it is possible that if you are providing your own toolchain, like the own from Android, the conan one is not very used. Some of the things that this toolchain does for cmake:
- Skip Rpath in OSX
- Define the MSVC runtime (MT, MD) based on Conan settings
- Define the libcxx based on Conan settings
- Define the cppstd based on Conan settings.
It is likely that some of these are irrelevant or unused. But yes, having a way to inject another toolchain is easy and useful.
| CMAKE_C_FLAGS_DEBUG CMAKE_CXX_FLAGS_DEBUG) | ||
| if(DEFINED ${flag}) | ||
| string(REPLACE "/MD" "/MT" ${flag} "${${flag}}") | ||
| endif() |
There was a problem hiding this comment.
Even though CMake won't add these flags by itself with CMP0091=NEW, can they be added by the user to the CONAN_<>_FLAGS? to environment variables? Is this something we want to cover or let the user realize about it?
| # TODO: I would want to have here the path to the compiler too | ||
| build_type = self._build_type if not is_multi_configuration(self._generator) else None | ||
| try: | ||
| # This is only defined in the cache, not in the local flow |
There was a problem hiding this comment.
Is this not what ConanFile.in_local_cache is for?
There was a problem hiding this comment.
The rationale when I coded that was that I didn't want to rely on that, I was aiming to have exactly the same experience both in the local cache and in the user local flow. So as long as the "package_folder" is defined, I would like this code to work. We need to think about this local flow with toolchains, this is a minor implementation detail.
There was a problem hiding this comment.
On another note, why use package_folder instead of install_folder?
Nvm, should've read docs more carefully.
Changelog: Feature: New
toolchain()recipe method, as a new paradigm for integrating build systems, and simplifying developer flows.Docs: conan-io/docs#1729
Close #7112
Simplifying, supersede #5919
This feature intruduce the
toolchainnew concept:toolchain()recipe method, that can use aCMakeToolchainobject to define build system logic for the current package, this is not related to dependencies at alltoolchain()is called atconan installtime. Building with the bare build system and the toolchain should always be identical to building with Conan (build() method).conan_toolchain.cmakeandconan_project_include.cmakefiles with all the logic that can be loaded with-DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmakeCMake()build helper that is used together with the toolchain, is way simpler, does way less thing, callingcmakewith the toolchain and the generator (necessary for VS, for example).cmake_find_packagegeneratorPending/missing/todo:
install_folderinformation totoolchain()method, for user custom file creation.#tags: slow