conan-io
New CMakeDeps
Changelog: Feature: Model cpp_info.exes field for executable applications
Changelog: Feature: Generate IMPORTED executable targets in CMakeDeps for cpp_info.exes
Docs: https://github.com/conan-io/docs/pull/XXXX
Close https://github.com/conan-io/conan/issues/7240 Close https://github.com/conan-io/conan/issues/13560 Close https://github.com/conan-io/conan/issues/16990 Close https://github.com/conan-io/conan/issues/16688 Close https://github.com/conan-io/conan/issues/12012 Close https://github.com/conan-io/conan/issues/12180 Close https://github.com/conan-io/conan/issues/14606
Could these issues also be addressed in the reworked CMakeDeps, maybe?
- #12180
- #12012
- #15386
The need to set CMAKE_TRY_COMPILE_CONFIGURATION is a very common pitfall when building external projects, but I suppose it might be unavoidable if the CMakeDeps wants to support multi-config CMake generators.
What are the interface implications of this new generator? It seems like it will break any invocation of find_package(XYZ REQUIRED MODULE) - are there other cases where behaviour of this deviates from the existing CMakeDeps generator and would introduce a breaking change? Should I expect for this to "mostly" be substitutable for the existing CMakeDeps generator?
It is not intended to break them, it is just that at this first iteration it is not implementing MODULE, and focusing on a correct behavior for Config.cmake files, which is the most important use cases. Modules will follow in next iterations. It is not a deviation, it is a functionality not implemented yet, the intent is that it can be a replacement of the previous generator in most cases, and also fully transparent in most cases.