[bug] find_package can't find config files if cross compilation/2 profiles #9202
Comments
SpaceIm
changed the title
|
I have tried with Windows and Linux (I don't have a Mac), and even when the profile host and profile build are different (I tried compiling for 32 bits), it works. Someone else that could try in OSX->iOS, please? @SpaceIm it would be good to know if this is a 1.38 regression, and it used to work in 1.37 or also failing in previous Conan versions. |
|
I don't know for older versions of conan, I'll try. |
|
I've tried with conan 1.35.0, 1.36.0 and 1.37.0, it fails with the same error. |
|
Thanks for the detailed report, I could reproduce the error on Macos, I'll try to investigate further what could be the issue. |
|
I think this issue was solved for OSX in the CMakeToolchain by @lasote, adding the XXX_DIR variable to packages for OSX exclusively. |
|
Hi, yes, the new Edit: The root cause is that CMake only search the Macos folders when crossbuilding. Another weird and unexpected behavior to be honest. |
|
I have closed without merging #9250, this is solved in the new CMakeToolchain, fixing it in the old ones is complicated and risky, it only applies to one very specific scenario (OSX and cross-build) and a workaround is relatively straightforward. Thanks all! |
|
@memsharded When you say "new CMakeToolchain", you refer to CMakeDeps? FYI, this issue breaks several build of CCI recipes, and many test_package, so it prevents CCI to add a configuration for iOS. CCI can't use CMakeDeps for the moment, and some recipes must model Find AND config files because they are different (like protobuf). |
No, it is included in the
How can it break the build, if CCI is not cross-building and not using 2 profiles? It is not intended to add iOS as a configuration to ConanCenter.
It will also be possible to use CMakeDeps and CMakeToolchain in ConanCenter very soon. |
|
@memsharded It's true that CCI doesn't build binaries for iOS currently, but @jgsogo may add this profile conan-io/conan-center-index#6045 (comment). So yes it doesn't break CI of CCI, but it might break consumers using others profiles. It's not because CI of CCI doesn't test those profiles, that CCI recipes shouldn't support them. Here is a simple fix in |
|
Hi! This kind of addition/fixes/enhancements would be very valuable from the point of view of conan-center-index. Right now we are building Macos/armv8 using two profiles (cross-building from regular Macos) and we have fixed many recipes, not because now it works for this new configuration, but because in the way we have removed legacy and improve their quality for other configurations. Right now we are receiving a lot of PRs related to iOS, some of them adding support and some others just fixing things that were working but some PR broke (I've broken several recipes for other configurations while trying to add support for M1). It translates into many more PRs and more burden on some people that are really taking care of Gathering feedback from the community, we feel that it would be very valuable to add some of these configurations to ensure that the recipes are not broken when we fix something (M1, iOS, Android, Conan v2,...). The plan is to stop generating some of the current configurations following the lead of the new docker images and the data about most used configurations that we are starting to collect... and use that spare capacity to build other configurations that will be much more valuable. It will take time to provide this capability in ConanCenter, I'm not sure if by that time all the new CMakeDeps/CMakeToolchain will be fully available and stable. Anyway, the sooner we can have the right recipes for these configurations, the better, that way contributors can work on consumer recipes, otherwise whenever we find one of these blockers, we cannot work on dependents... and it really takes time to progress on the graph of dependencies. |
|
Just to mention that the fact that
Here are several CCI recipes whose build is broken (not only test package) due to this issue:
|
|
@memsharded Sorry to bother you, but I have a fix that I've tested locally with several recipes in native and cross-build scenario: --- a/conans/client/generators/cmake_common.py
+++ b/conans/client/generators/cmake_common.py
@@ -108,6 +108,7 @@ set(CONAN_FRAMEWORKS_FOUND{build_type} "") # Will be filled later
set(CONAN_DEFINES{build_type} {deps.defines} ${{CONAN_DEFINES{build_type}}})
set(CONAN_BUILD_MODULES_PATHS{build_type} {deps.build_modules_paths} ${{CONAN_BUILD_MODULES_PATHS{build_type}}})
set(CONAN_CMAKE_MODULE_PATH{build_type} {deps.build_paths} ${{CONAN_CMAKE_MODULE_PATH{build_type}}})
+set(CONAN_CMAKE_FIND_ROOT_PATH{build_type} {deps.build_paths} ${{CMAKE_CURRENT_LIST_DIR}} ${{CONAN_CMAKE_FIND_ROOT_PATH{build_type}}})
set(CONAN_CXX_FLAGS{build_type} "{deps.cxxflags} ${{CONAN_CXX_FLAGS{build_type}}}")
set(CONAN_SHARED_LINKER_FLAGS{build_type} "{deps.sharedlinkflags} ${{CONAN_SHARED_LINKER_FLAGS{build_type}}}")Would you consider a PR for this issue? |
it's worth noting that recipe still fails if cross-building to iOS due to conan-io/conan#9202
* fix bundle destination for iOS/tvOS/watchOS it's worth noting that recipe still fails if cross-building to iOS due to conan-io/conan#9202 * bump leptonica * no os.rename * move checks to validate()
…nize * fix bundle destination for iOS/tvOS/watchOS it's worth noting that recipe still fails if cross-building to iOS due to conan-io/conan#9202 * bump leptonica * no os.rename * move checks to validate()
|
After more experimentations, the less fragile solution I've found is: --- a/conans/client/generators/cmake_common.py
+++ b/conans/client/generators/cmake_common.py
@@ -108,6 +108,7 @@ set(CONAN_FRAMEWORKS_FOUND{build_type} "") # Will be filled later
set(CONAN_DEFINES{build_type} {deps.defines} ${{CONAN_DEFINES{build_type}}})
set(CONAN_BUILD_MODULES_PATHS{build_type} {deps.build_modules_paths} ${{CONAN_BUILD_MODULES_PATHS{build_type}}})
set(CONAN_CMAKE_MODULE_PATH{build_type} {deps.build_paths} ${{CONAN_CMAKE_MODULE_PATH{build_type}}})
+set(CONAN_CMAKE_FIND_ROOT_PATH{build_type} ${{CMAKE_CURRENT_LIST_DIR}} ${{CONAN_CMAKE_FIND_ROOT_PATH{build_type}}})
set(CONAN_CXX_FLAGS{build_type} "{deps.cxxflags} ${{CONAN_CXX_FLAGS{build_type}}}")
set(CONAN_SHARED_LINKER_FLAGS{build_type} "{deps.sharedlinkflags} ${{CONAN_SHARED_LINKER_FLAGS{build_type}}}")${{CMAKE_CURRENT_LIST_DIR}} => for conan generated config files {deps.build_paths} can't be added, because it would put executables paths of host context in But
|
|
Another solution:
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH) # for find_library()
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH) # for find_file() and find_path()
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE BOTH) # for find_package()
# maybe also CMAKE_FIND_ROOT_PATH_MODE_PROGRAM?Problems appear when they are automatically set to https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html#variables-that-change-behavior |
Environment Details (include every applicable attribute)
Steps to reproduce (Include if Applicable)
conan create . re2/20210601 -pr:b profile_build -pr:h profile_host(profile_build and profile_host must be different, otherwise it works).example of profiles on macOS:
profile_build:
profile_host:
Logs (Executed commands with output) (Include/Attach if Applicable)
Is it related to CMake helper? conan_basic_setup()? I don't know. From what I saw,
CMAKE_PREFIX_PATHandCMAKE_MODULE_PATHare properly set, andre2-config.cmakeis located in build folder of test package.If I replace in test package
cmake_find_package_multibycmake_find_package, andfind_package(re2 REQUIRED CONFIG)byfind_package(re2 REQUIRED), it works.This is a simple example, but this issue breaks cross compilation of several more complex CCI recipes where CMake configuration of the lib itself relies on discovery of CMake config files generated by
cmake_find_package_multi(I've seen this issue inlibgeotifforiginally, after fixing cross compilation issues of its (transitive) dependencies like proj, sqlite3 or jbig).The text was updated successfully, but these errors were encountered: