Cmake find mode copy provided #18816
Conversation
… files to be provided in place of the generated ones. Works better with cmake-conan plugin.
|
|
|
Currently I am using the Conan generated targets.cmake and targets-.cmake files because the link path doesn't propagate correctly when using the project generated ones. This creates problems when setting the INSTALL_RPATH on project installed targets using INSTALL_RPATH_USE_LINK_PATH, which should contain all the directories of the conan packages. I'm not sure why this is the case. I would prefer to use the project generated ones if possible, as they can contain linking information for targets that Conan may not be managing. For example if I'm using an optional CUDA-enabled feature with one of the linked targets, conan doesn't manage cuda at all, so it the linker/include paths won't be propagated. Yeah I just confirmed that adding a CUDA feature flag to one of the dependencies (uses system-installed CUDA) doesn't work: The project generated Target files contain this information, but I don't think Conan is setting up some of the linker path information correctly if I use those. I may need some help to get Conan to use these paths correctly using all of the project provided files instead. |
|
I just updated this branch using my old method, which looks to correctly import everything including CUDA targets if the project was built with them. It just has issues with propagating the imported library paths to the linker path and INSTALL_RPATH. Can anyone help me figure out how conan sets those, i.e. why it works correctly with the conan generated files, and would could cause that to not work with the CMake generated ones? In this workflow, the path that the libraries are copied to in the conan-generators folder OR the original package folder should be on the linker path, and so should be propagated into the install target. But this is not the case: tstrutz@BAH5CG333536R:~/development/conan$ ldd ~/Install/bin/dewmars
linux-vdso.so.1 (0x00007fff00326000)
libDEWMARS_SignalProcessing.so => /home/tstrutz/Install/lib/libDEWMARS_SignalProcessing.so (0x00007e3c9e223000)
libqcustomplot.so.2 => /home/tstrutz/.conan2/p/b/qcust335835ec573c5/p/lib/libqcustomplot.so.2 (0x00007e3c9e0c0000)
libQt5Widgets.so.5 => /home/tstrutz/.conan2/p/b/qt3a3f22f8977b9/p/lib/libQt5Widgets.so.5 (0x00007e3c9d800000)
libQt5Core.so.5 => /home/tstrutz/.conan2/p/b/qt3a3f22f8977b9/p/lib/libQt5Core.so.5 (0x00007e3c9d000000)
libDEWM.so => not found
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007e3c9cc00000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007e3c9e086000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007e3c9c800000)
libQt5Network.so.5 => /home/tstrutz/.conan2/p/b/qt3a3f22f8977b9/p/lib/libQt5Network.so.5 (0x00007e3c9df31000)
libQt5Sql.so.5 => /home/tstrutz/.conan2/p/b/qt3a3f22f8977b9/p/lib/libQt5Sql.so.5 (0x00007e3c9deec000)
libQt5Concurrent.so.5 => /home/tstrutz/.conan2/p/b/qt3a3f22f8977b9/p/lib/libQt5Concurrent.so.5 (0x00007e3c9dee3000)
libDEWM.so => not found
libQt5Gui.so.5 => /home/tstrutz/.conan2/p/b/qt3a3f22f8977b9/p/lib/libQt5Gui.so.5 (0x00007e3c9c000000)
libcudart.so.12 => /usr/local/cuda-12.9/targets/x86_64-linux/lib/libcudart.so.12 (0x00007e3c9bc00000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007e3c9d719000)
/lib64/ld-linux-x86-64.so.2 (0x00007e3c9e43a000)
libQt5PrintSupport.so.5 => /lib/x86_64-linux-gnu/libQt5PrintSupport.so.5 (0x00007e3c9cf88000)
libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007e3c9cf01000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007e3c9dedc000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007e3c9ded7000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007e3c9ded2000)
libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007e3c9ce49000)
libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007e3c9d6e5000)
libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007e3c9cac0000)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007e3c9d6bb000)
libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007e3c9deca000)
libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007e3c9ce41000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007e3c9caa8000)
libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x00007e3c9ce34000)RPath of this binary: tstrutz@BAH5CG333536R:~/development/conan$ objdump -x ~/Install/bin/dewmars |grep 'R.*PATH'
RUNPATH /home/tstrutz/ARCEM-Install/lib:/home/tstrutz/.conan2/p/b/qt3a3f22f8977b9/p/lib:/home/tstrutz/.conan2/p/b/qcust335835ec573c5/p/lib:/home/tstrutz/.conan2/p/b/xkbco7f538552220db/p/lib:/usr/local/cuda-12.9/targets/x86_64-linux/lib:/home/tstrutz/.conan2/p/midas5c079fb898566/p/lib:/home/tstrutz/.conan2/p/matla49a7238405701/p/lib:/home/tstrutz/.conan2/p/b/vclma45866bf1f434d/p/lib |
There was a problem hiding this comment.
Thanks very much for your contribution @tstrutz
Some general comments:
- Avoid introducing typing annotations, we don't use them in the codebase, they will be introduced just in the ConanAPI at this time, and gradually
- All PRs should have accompanying new tests. This one will need integration + functional tests
No need to do any changes yet, please don't work yet on tests or do any changes.
It seems there could be some functional and architectural issues to consider carefully in this PR, and specially we should align first in the approach to follow, there could be different angles.
So lets think first about the problem, we will follow up and discuss in the issue you filed here #18815. Thanks again!
| ret[config_filename] = self._read_project_provided_cmake_file(config_filename, dep) | ||
| ret[version_filename] = self._read_project_provided_cmake_file(version_filename, dep) | ||
| ret[targets_filename] = self._read_project_provided_cmake_file(targets_filename, dep) | ||
| ret[target_configuration_filename] = self._read_project_provided_cmake_file(target_configuration_filename, dep) | ||
| deduced_cpp_info : CppInfo = dep.cpp_info.deduce_full_cpp_info(self._conanfile) |
There was a problem hiding this comment.
The problem with this is that the files that projects provide might have different names, the "Targets" files is mostly a convention, but not mandatory. This will not work in many cases, and it is necessary a more general approach
There was a problem hiding this comment.
Should we provide the ability to pass in the corresponding names of these files then? I tried to use mostly existing code to generate these filenames.
Or just leverage the existing conan variables such as cmake_file_name etc?
| ConanOutput(self._conanfile.ref).info(f"Installing libs found in {deduced_cpp_info.location} and includes in {deduced_cpp_info.includedirs} to IMPORT_PREFIX location") | ||
| lib_folder = os.path.join("..", "lib", self.configuration) | ||
| os.makedirs(lib_folder, exist_ok=True) | ||
| shutil.copy(deduced_cpp_info.location, lib_folder) | ||
| shutil.copytree(deduced_cpp_info.includedir, os.path.join("..", "include"), dirs_exist_ok=True) | ||
| # Copy the component libraries. | ||
| for name, lib in deduced_cpp_info.components.items(): | ||
| shutil.copy(lib.location, lib_folder) |
There was a problem hiding this comment.
A generator shouldn't be copying artifacts like headers or libs around, that is more the responsibility of a deployer.
There was a problem hiding this comment.
Would you recommend moving this somewhere else in the code base, or just not doing this step entirely? This is how I attempted to make the files relocatable using the ${_IMPORT_PREFIX} which points to parent directory of the folder.
Another alternative might be to edit this path so that include/lib references for each target point back to the conan package.
Changelog: (Feature | Fix | Bugfix): Describe here your pull request
Docs: https://github.com/conan-io/docs/pull/XXXX
developbranch, documenting this one. Added documentation for copy cmake_find_mode. docs#4202