Improved resolving libraries for cross-compilation use-case

[redradist]

This update is useful for cross-compilation, because some cross-compilers better workers with direct path to library

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[redradist]

@czoido Could you please review this changes ?

[czoido]

Hi @redradist Thank you for the contribution. Could you please give me more context of why this is useful in the cross-compilation case?

[redradist]

Hi @redradist Thank you for the contribution. Could you please give me more context of why this is useful in the cross-compilation case?

@czoido It is helpful, because when on embedded system you try to link library it cannot be found because library is searched first in rpath ... But it works much better with full path that can be provided by find_library call first

[czoido]

Hi @redradist, Sorry for responding late. I have been having a look at this and I think that this should not be solved in cmake-conan, this comes probably from the Conan cmake generator that is not resolving the absolute paths for the libraries. I have opened a PR in Conan to check if that change has further implications that I might not know.

[czoido]

Hi @redradist, After considering this issue, I think we can't fix that in Conan because it may break users that maybe are checking the content in CONAN_LIBS and making some processing steps like this find_library one. For the same reason we can't merge this into cmake-conan. Also, this global approach using CONAN_LIBS is tending to be deprecated for Conan 2.0. I have checked that this works using a targets approach, I would suggest you switch from using CONAN_LIBS to linking with the generated targets which means changing from this:

include(conan.cmake)
conan_cmake_run(REQUIRES fmt/6.1.2
                BASIC_SETUP
                BUILD missing)
add_executable(main main.cpp)
target_link_libraries(main ${CONAN_LIBS})

to this

include(conan.cmake)
conan_cmake_run(REQUIRES fmt/6.1.2
                BASIC_SETUP CMAKE_TARGETS
                BUILD missing)
add_executable(main main.cpp)
target_link_libraries(main CONAN_PKG::fmt)

Other option is adding that find_library code to your CMakelists.txt.

Please tell me if this helps.

[redradist]

Hi @redradist, After considering this issue, I think we can't fix that in Conan because it may break users that maybe are checking the content in CONAN_LIBS and making some processing steps like this find_library one. For the same reason we can't merge this into cmake-conan. Also, this global approach using CONAN_LIBS is tending to be deprecated for Conan 2.0. I have checked that this works using a targets approach, I would suggest you switch from using CONAN_LIBS to linking with the generated targets which means changing from this:

include(conan.cmake)
conan_cmake_run(REQUIRES fmt/6.1.2
                BASIC_SETUP
                BUILD missing)
add_executable(main main.cpp)
target_link_libraries(main ${CONAN_LIBS})

to this

include(conan.cmake)
conan_cmake_run(REQUIRES fmt/6.1.2
                BASIC_SETUP CMAKE_TARGETS
                BUILD missing)
add_executable(main main.cpp)
target_link_libraries(main CONAN_PKG::fmt)

Other option is adding that find_library code to your CMakelists.txt.

Please tell me if this helps.

@czoido Okay, but with CONAN_PKG:: I have to repeat myself ...

Then maybe we should introduce a new variable like ${CONAN_PKGS} that will contain full paths to library ?

[czoido]

Hi @redradist, I'm afraid that adding more variables for a way of using Conan we are not recommending any more and that will be removed in Conan 2.0 does not feel like best approach. I would recommend to add that find_library code in your own CMakelists.txt if you need it or move to cmake_find_package generator that will be the default way for support in the future.

[redradist]

Hi @redradist, I'm afraid that adding more variables for a way of using Conan we are not recommending any more and that will be removed in Conan 2.0 does not feel like best approach. I would recommend to add that find_library code in your own CMakelists.txt if you need it or move to cmake_find_package generator that will be the default way for support in the future.

@czoido Okay, I got your point, but it is not convenient to do the same thing in each CMakeLists.txt ... Maybe better to add conan_cmake_run like FIND_PACKAGE, in this case you will not break backward compatibility and at the same time provide for other users convenient flag ?

[LeeRuns]

I am following the directions exactly and have a similar problem. Here my failure is generated by "Findmypackage.cmake" which was generated by conan. It fails to find the .lib files required. So this seems to be a more current problem with the new find-package workflow.