Using `virtualrunenv` in `cmake`

[tvogel]

Using cmake-conan with virtualrunenv, I create an activate_run.sh which I need because I am using a custom conan-built Qt 5 with autogen and a custom icu version, so uic can only be run with LD_LIBRARY_PATH being set up to point to the correct icu conan-libdir. Of course, I can now manually bash --init-file activate_run.sh and run make from there but obviously it would be way better if cmake-conan could source activate_run.sh when running helpers (or have a different method to set up the virtual run-env). It's in particularly necessary for calling moc, uic and rcc. Are there already options available that I don't see?

[rasjani]

disclaimer; I'm not a dev here, just a user.

Virtual environments rely modifying the environment of the current active shell. In order to have "active" virtual environment. If there would be venv activation inside cmake calls, those activations should happen to all calls that end up running any external tooling. I doubt cmake would have an option to do that nicely.

[spiderkeys]

I was also curious if such a thing was possible. If you are building your package with a conanfile.py, you can easily do this in the build() function by invoking cmake with with tools.run_environment(self):, but typically you aren't building an end Qt application with a conanfile, but instead are doing a plain cmake build or using an IDE like QtCreator.

In this case the only tool that actually needs the virtual environment is a the uic binary included within the qt conan package itself. It almost seems as if the qt package should simultaneously be considered a requirement and build_requirement, with the binaries provided comprising the build_requirement aspect of it. At this point, and in consideration of @rasjani's take, I'm wondering if this is an issue with how conan-qt is packaged, rather than with cmake-conan.

Maybe there is a way to either modify the conan-qt package to cleverly provide its lib paths to uic (maybe through a symbolic link or script that calls the actual uic?) or split the autogen tools out into a build tool package that imports its executables and libraries from the qt dependency and sets them up to find their libraries properly.

Would be interested to hear the opinions of the cmake-conan devs on this particular scenario and what the right way to go about solving this type of "library package contains executables needed for build steps, and depends on shared libraries" use-case might be. I could see this also being an issue with communication libraries that contain code generation executables for generating source code from IDL files.