[bug] CMakeDeps: issues when import library (.lib) and DLL (.dll) have a different filename

[jcar87]

Describe the bug

CMakeDeps uses the library name passed to cpp_info.libs to locate both the import library (.lib) and the DLL (.dll):

conan/conan/tools/cmake/cmakedeps/templates/macros.py

Lines 60 to 67 in 157aa67

	if(is_host_windows AND library_type STREQUAL "SHARED")
	# Store and reset the variable, so it doesn't leak
	set(_OLD_CMAKE_FIND_LIBRARY_SUFFIXES ${CMAKE_FIND_LIBRARY_SUFFIXES})
	set(CMAKE_FIND_LIBRARY_SUFFIXES .dll ${CMAKE_FIND_LIBRARY_SUFFIXES})
	find_library(CONAN_SHARED_FOUND_LIBRARY NAMES ${_LIBRARY_NAME} PATHS ${package_bindir}
	NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
	set(CMAKE_FIND_LIBRARY_SUFFIXES ${_OLD_CMAKE_FIND_LIBRARY_SUFFIXES})
	if(NOT CONAN_SHARED_FOUND_LIBRARY)

While it is common, it is not a hard requirement for both files to have the same leaf name but a different extension. We can link against a foo.lib that will introduce a dependency on bar.dll (instead of foo.dll), and it is perfectly valid - the name of the corresponding dll is encoded in the import library. According to a comment here: https://stackoverflow.com/questions/52821978/get-a-dll-name-from-import-library, a single .lib may require multiple DLLs (although we need to find a more authoritative source for this)

However, the cpp_info.libs model does not have a facility to express cases where the filenames are different. Conan will display a warning, as in most cases, CMake does "nothing" with the DLL and only the .lib file is required to link. However, some consumer projects may perform target introspection to derive the name of the DLL.

Details here conan-io/conan-center-index#25076 (comment)

Related to: #12654

How to reproduce it

No response

[memsharded]

Now we start to have a way to start specifying these things, since CPS initial support was merged:

def package_info(self):
      self.cpp_info.libs = {"mylib": {"location": "path/to/MY_LIB.dll",
                                                    "link_location": "path/other/my_importname.lib"}
                                     }

This is still not used at all by CMakeDeps, but we have a way to pass information, it would be necessary to start leveraging it in CMakeDeps.

[chfuerst]

Hello,

i have encountered the same situation. When building curl 7.85.0 in Windows as a shared library, i get

• lib/libcurl_imp.lib
• bin/libcurl.dll

where libcurl_imp is actually an import library, and in particular, the generated cmake-files specify

set_target_properties(CURL::libcurl PROPERTIES
  IMPORTED_IMPLIB_RELEASE "${_IMPORT_PREFIX}/lib/libcurl_imp.lib"
  IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/bin/libcurl.dll"
  )

which should be able to be set by the package_info method.

Is there a work-around?

[memsharded]

Hi @chfuerst

We have added a new CMakeDeps generator in Conan 2.9 that will implement explicitly the management of the imported location and link location.

@franramirez688 is working also on better auto-detection of these libraries in the Python code, please @franramirez688 make sure to add this case to the test suite

[chfuerst]

Thank you very much @memsharded - i have tried to read from the documentation how to explicitly overwrite the names.
In conan 2.9.2 in the file conan/tools/cmake/cmakedeps/templates/macros.py i have found the boilerplate

set_target_properties(${_LIB_NAME} PROPERTIES IMPORTED_LOCATION${config_suffix} ${CONAN_SHARED_FOUND_LIBRARY})
set_target_properties(${_LIB_NAME} PROPERTIES IMPORTED_IMPLIB${config_suffix} ${CONAN_FOUND_LIBRARY})

which is assigned from the result of

find_library(CONAN_FOUND_LIBRARY NAMES ${_LIBRARY_NAME} PATHS ${package_libdir}
                            NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)

but unfortunately i do not see how different names of IMPORTED_LOCATION and IMPORTED_IMPLIB are handled.

Could you please give an example as in curl above?

Thx, Christoph

[memsharded]

Hi @chfuerst

This has been implemented in #17296, for next Conan 2.10. It will be used in the new CMakeDeps generator, which is still dev-testing only via -c tools.cmake.cmakedeps:new=will_break_next (the value will actually change in every release, to guarantee dev-testing only). Looking forward your feedback, please create new tickets if necessary against the new CMakeDeps.