0

I have a conan recipe of a package, named Package, that requires boost as a shared library:

def requirements(self):
        self.requires("boost/1.79.0@")
        self.options["boost"].shared = True
        self.options["boost"].bzip2 = False
        self.options["boost"].without_stacktrace = True

The used generators are CMakeDeps and CMakeToolchain.

def generate(self):
        tc = CMakeToolchain(self)
        tc.variables['BUILD_SHARED_LIBS'] = "ON" if self.options.shared == True else "OFF"
        tc.variables['CMAKE_FIND_ROOT_PATH_MODE_PACKAGE'] = 'NEVER'
        tc.variables['CMAKE_POSITION_INDEPENDENT_CODE'] = 'ON'


        tc.generate()

The unit tests of this conan package use a CMakeLists.txt which defines a PackageTests target that links against Package and boost::boost.

Building the Package and PackageTests works fine for both Ubuntu and Windows but only on Ubuntu the tests run without issues. On Windows I get exceptions for all the tests because the boost dlls are not found. Using ldd PackageTests and readelf -d PackageTests on Ubuntu shows that boost so files are used from the conan cache.

Using conans VirtualRunEnv generator and then activating the generated environement helps to also run the PackageTests.exe on Windows but I would like to know if there is another way using for example pure CMake to install/copy the required boost dlls to the bin/PackageTests.exe folder? Or is there a way to extend the conan recipe to install the dlls on Windows?

Why are boost shared libraries found correctly in the conan cache but not on Windows? Is there some extra manual work needed or shouldn't this be handeled by conan as well?

Edit: Trying to use the following to copy the dlls results in a cmake command usage error because the TARGET_RUNTIME_DLLS generator expression is empty.

add_custom_command(TARGET PackageTest POST_BUILD
  COMMAND ${CMAKE_COMMAND} -E copy_if_different $<TARGET_RUNTIME_DLLS:PackageTest > $<TARGET_FILE_DIR:PackageTest>
  COMMAND_EXPAND_LISTS
)

Also IMPORTED_LOCATION property for the following targets are *-NOTFOUND:

get_target_property(VAR-boost boost::boost IMPORTED_LOCATION)
message(${VAR-boost})
> VAR-boost-NOTFOUND

get_target_property(VAR-Package Package IMPORTED_LOCATION)
message(${VAR-Package})
> VAR-Package-NOTFOUND

get_target_property(VAR-Package PackageTest IMPORTED_LOCATION)
message(${VAR-Package})
> VAR-PackageTest-NOTFOUND

From the boost conan recipe package_info() I can see that the CMakeDeps generator will only create the BoostConfig.cmake and BoostTargets.cmake scripts, which is also the case for Package. There is no FindBoost.cmake generated. By default CMakeDeps only creates config scripts, except the recipes define cmake_find_mode to be both. Not sure though if adding both to the recipe could help. Even if it would help, this is no immediate solution as this is not directly in my control (hosted on conan-center-index repo). I am still not able to see the reason why everything works fine on Ubuntu but on Windows the dlls are not found/copied at all by conan.

evolved
  • 1,850
  • 19
  • 40
  • "I would like to know if there is another way using for example pure CMake to install/copy the required boost dlls to the bin/PackageTests.exe folder?" - Yes, [that question](https://stackoverflow.com/questions/10671916/how-to-copy-dll-files-into-the-same-folder-as-the-executable-using-cmake) is exactly about those ways. – Tsyvarev Nov 30 '22 at 22:48
  • The runtime dlls of `boost::boost` seem to be ignored by this `TARGET_RUNTIME_DLLS` generator expression. Is this because of the boost find package scripts are generated by conan and are in the conan cache? Is it possible to manually inspect the module variables to find the library paths and add custom commands? I mean compiling and linking works fine with `boost::boost` but why is the generator expression empty? – evolved Nov 30 '22 at 23:22
  • I also don't understand why on Ubuntu everything runs fine without exceptions and readelf and ldd point to the boost in the conan cache, but on Windows the shared libs (boost dlls) are not found at all. – evolved Nov 30 '22 at 23:24
  • Is there a way to test if the imported boost target is of type `UNKNOWN`? https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#genex:TARGET_RUNTIME_DLLS – evolved Nov 30 '22 at 23:33
  • "Is there a way to test if the imported boost target is of type `UNKNOWN`? - As a simple check, you could read value of `IMPORTED_LOCATION` property for the target. If that value contains path to `.lib` file, then `TARGET_RUNTIME_DLLS` cannot resolve path to dll file in any case. Please, incorporate details of your **attempt** into the **question post**. In the current form your question post looks like the duplicate of [the question](https://stackoverflow.com/questions/10671916/how-to-copy-dll-files-into-the-same-folder-as-the-executable-using-cmake) pointed by me. – Tsyvarev Dec 01 '22 at 09:24
  • Thanks @Tsyvarev for the help! I updated my question and it seems that the `IMPORTED_LOCATION` of the boost target is not set correctly. I guess this is an issue by the conan `CMakeDeps` generator or the conan recipe for boost itself? – evolved Dec 01 '22 at 10:37
  • As far as I know I need to make use of `TARGET_RUNTIME_DLLS` because the location from where I want to copy the boost dlls is not always the same. The conan cache where the boost dlls are taken from is in the home folder of every user and it changes depending on the boost version. So I don't think a fixed path to copy the dlls from is going to work, as it is more or less done in most of the answers from the question you posted. – evolved Dec 01 '22 at 10:43
  • What's strange the dlls are there during build time. Is there a way to copy the files during this step to the PackageTest target? – evolved Dec 01 '22 at 10:46
  • I understand many things about CMake, but I know a little about Conan. So I cannot help in questions about Boost which are specific to its installation via Conan. Maybe someone else with corresponing knowledge will find your question. Make sure that given person will find all relevant information in the **question post**, without needing to read all the comments. E.g. in the current form of your question it is absolutely not clear, that you attempted to use `TARGET_RUNTIME_DLLS` for collect libraries for copy. – Tsyvarev Dec 01 '22 at 11:11
  • Conan generated targets might not have all the properties defined in Conan 1.X. The situation will improve a bit in 2.0. In the meantime, it is better to use Conan ``imports`` feature to collect DLLs, if that is the case. For further discussion, the best is to file a ticket in the Github repo. – drodri Dec 05 '22 at 12:33

0 Answers0