[question] LD_LIBRARY_PATH and DYLD_LIBRARY_PATH are not added in CMakePresets.json

[DominicPicard]

What is your question?

Hi,

We use WSL to build our Linux configurations. We have a few dependencies that are built as shared libraries. When we run conan install, the LD_LIBRARY_PATH and DYLD_LIBRARY_PATH are not added the environment section of the CMakePresets.json.

The issue is that the unit test project won't run since the .so files are not found.

The work around is to manually copy LD_LIBRARY_PATH and DYLD_LIBRARY_PATH from conanenvto the generated CMakePresets.json

I was wondering if it was a known issue or if maybe there was something that we do not do correctly. We cannot use conanenv script since we use Visual Studio on Windows to build the Linux configurations. Visual Studio does not know about conanenv. But it will use the environment variable that are set in CMakePresets.json.

Thank you for your time :)

Dominic

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[DominicPicard]

Ok ! I found what I was looking for in the documentation I can compose the preset environment to append the 'runtime' environment to the build environement

tc.presets_build_environment = VirtualBuildEnv(self).environment().compose_env(VirtualRunEnv(self).environment())

[memsharded]

Hi @DominicPicard

Great that you found a solution.

However, depending on the context, this shouldn't be necessary? The VirtualRunEnv is already added to the test presets, isn't that enough for your use case?

The CMakeToolchain is adding dependencies bindirs to the CMAKE_VS_DEBUGGER_ENVIRONMENT, I guess this is not valid or not being filled, because the CMake generator is not a Visual Studio one? What is the CMake generator that you are using?

I am thinking that it might be good to try to have a more built-in way to allow running Linux binaries from the IDE if possible, in the same way it is possible for Windows VS binaries.

[DominicPicard]

Hi @memsharded

Thank you for your quick reply :)

We are using the CMakeDeps and CMakeToolchain. The conan install creates a CMakeUserPresets.json that points to CMakePresets.json files that are specific to each configuration. We run conan install for each or our profile.

In each of our Conan packages, we have unit tests project(s) and these test projects use the post-build command gtest_discover_tests. That post-build command requires the .so/.dll to be found.

It does not seem like Visual Studio uses the test preset.

[memsharded]

In each of our Conan packages, we have unit tests project(s) and these test projects use the post-build command gtest_discover_tests. That post-build command requires the .so/.dll to be found.

I see, if the tests are not executed as tests, and the discovery needs the "host" shared libs .so to be available, then indeed it would be necessary to make the VirtualRunEnv available at "build" scope too. I think it is valid to think if some better syntax or built-in way can be used to express this, I am re-opening it (not a high priority yet, but if it is close it will draw even less attention).

Maybe something that you can also try is to inject the CMAKE_VS_DEBUGGER_ENVIRONMENT cmake variable paths as environment PATH in your post-build command, that might also be an interesting workaround.

[proceduralnoisy]

Related issues: #12782, #16070

We ran into this issue recently. Enabling VirtualRunEnv at "build" scope is one possible solution. A simple alternative is to defer the test discovery until after the build phase using the DISCOVERY_MODE option:

gtest_discover_tests(<target name> DISCOVERY_MODE PRE_TEST)

In any event, an out-of-the-box Conan solution would be welcome. Since gtest_discover_tests() appears to be the recommended replacement for add_test() when using GoogleTest, I suspect this will be a common stumbling block, given GoogleTest's widespread usage in the industry.

[Minimonium]

The same issue affects catch_discover_tests, which is the same functionality in Catch2.