Windows DLLs on the PATH

[FWiesner]

so, we have a commercial binary package that we bundle up using Conan 2.11.0. Our own project builds on Windows and Linux and as the dependency contains a DLL, we package the dependency package for Windows with the following standard structure

• headers in f"{self.package_folder}/include"
• the linker library in f"{self.package_folder}/lib"
• the dll and its pdb for debug in f"{self.package_folder}/bin"

package_info also includes (as proposed by AI)

self.runenv_info.define("PATH", os.path.join(self.package_folder, "bin"))

So, packaging works and linking as well. When trying to run the application that depends on the package from the IDE (latest CLion), Windows unfortunately reports that the DLL could not be found.

Now I wonder whether

• my binary dependency recipe is bad or
• whether I need to use extra CMake macros/functions from cmake-conan or
• whether I need to plug cmake-conan somehow into cmake install
• or whether it is a totally different thing.

I would really like to understand what's wrong here.

Thanks in advance,
Florian

[FWiesner]

actually, I guess the most versatile option would be to be able to use

find_package(${conan_managed_dep} REQUIRED)
install(TARGETS ${conan_managed_dep_target_name} DESTINATION ${location})

But, trying this with the target names produced by cmake-conan this will not work as the targets cannot be found.

Say, cmake-conan logs

Conan: Target declared 'foo::foo'

then it seems that this target is only available internally to Conan and is not made available to my build

[memsharded]

Hi @FWiesner

Thanks for your feedback

self.runenv_info.define("PATH", os.path.join(self.package_folder, "bin"))

In theory this is not necessary. As long as the binaries are in the bindirs folder (which by default is bin, this will be done automatically.

So, packaging works and linking as well. When trying to run the application that depends on the package from the IDE (latest CLion), Windows unfortunately reports that the DLL could not be found.

The location of binaries for debugging/running in the IDE is defined at the moment by CMAKE_VS_DEBUGGER_ENVIRONMENT variable which is defined by CMakeToolchain.
That means that via cmake-conan it is not possible to use it, as cmake-conan cannot make use of the toolchain, as CMake is the one driving the build.
We are trying to change that, and the new incubating CMakeDeps (see https://docs.conan.io/2/incubating.html) will generate an extra file (not a toolchain) that will be injected by the cmake-conan code to be able to use it.

I'll try to make a proof of concept today if possible about this, it might take a bit to fully connect all the pieces, but lets keep moving forward.

[memsharded]

Correction: what I am trying only applies for VS, not CLion, not sure what is the correct setup for CLion for this case.
Still, the new strategy for cmake-conan with the new file has to be pushed, will solve other cmake-conan issues, so I will work on this.

[FWiesner]

I had reached out to Jetbrains for CLion support when the project you run has the need to load DLLs that are in different build (sub-)directories. Their recommendation is to stage everything together and that is the reason why I am thinking of the use of install as indicated in my second post.

https://youtrack.jetbrains.com/issue/CPP-42831/Steps-unclear-to-launch-executables-with-CLion-on-Windows-where-DLL-and-executable-targets-are-built-in-different-directories

[memsharded]

Proposing:

• add vs_debugger info to incubating CMakeDeps conan#17561
• proposal for loading conan_cmakedeps_paths.cmake #674

[FWiesner]

until the new CMakeDeps moves from incubation to maturity, I wonder whether I could reliably leverage ${package-name_PACKAGE_FOLDER_DEBUG} (in case of a debug build)

[memsharded]

until the new CMakeDeps moves from incubation to maturity, I wonder whether I could reliably leverage ${package-name_PACKAGE_FOLDER_DEBUG} (in case of a debug build)

This is an internal implementation detail, but on the other hand, it is not very likely to change its name in the following releases, so might be a possible workaround in the meantime. The disadvantage is that you need to know the package names and iterate them or something like that, there is no aggregated variable for this. Also, it also needs to assume that the dlls to pick are always in the "bin" folder of the package. 99% of the times it is this way, but it might be possible to find some package that puts the binaries in some other unconventional directory.