[question] How to handle PATH variable in windows

[mikirothman]

What is your question?

Hello,

we use mainly windows for our applications, in some of them, we are using large dependency graph where all packages contribute to the PATH env-var (SHARED_LIBS). so the run environment is pretty large, currently we are not using any custom conan cache folder, or any custom deployer.

for our build environment, we use cmake + ninja + vcvars which adds many Visual studio folders to the path.

now, we've added ctest support, so we need both build environment and run environment to our builds. this combination exceeds the PATH size limit, and we are looking for a solution.

as for the runenv we start by set conan cache closer to C drive, we don't have a solution to shorter the build envieonment. do you have any recommendations on that issue ?

Have you read the CONTRIBUTING guide?

• [ ] I've read the CONTRIBUTING guide

[memsharded]

Hi @mikirothman

That is indeed a very annoying limitation of Windows (that still happens in 2023...), and the mitigations could be:

• Might try to run using one the conanrun environment, dropping the conanbuild one, as in theory, VS and other build-requirements shouldn't be necessary to run the tests executables
• Sometimes, using powershell might extend things a bit, as .bat files have some extra limitations
• But for the general case, using a deployer to deploy the .dlls to common folder is the only thing that could help. (we are willing to add a runtime deployer to the built-ins, but at the moment you might need to use your own one (you can start from the example one in the conan-extensions Github repo)

How many different packages containing shared libraries do you have?

[mikirothman]

thanks for the response.

• the only reason we need the conanbuild to run the tests is cause we are using CMake as tool_requires, and we get the ctest executable from the VirtualBuildEnv generator. we might choose to install CMake rather than use conan cache to manage it as a solution.
• Do you have any idea when the runtime deployer is going to be released ?
• We have many different projects that consume various number of our own packages, currently we are in the process of breaking some very big and monolith packages into smaller pieces, so nowadays I guess we are speaking on ~packages for the deepest tree, but it's going to grow to around 40.
• we use mainly shared libs builds, although the dependencies should be consumable VIA static libs for different interpretation of our products.

[memsharded]

the only reason we need the conanbuild to run the tests is cause we are using CMake as tool_requires, and we get the ctest executable from the VirtualBuildEnv generator. we might choose to install CMake rather than use conan cache to manage it as a solution.

You might try to activate only the specific file that includes the vars from dependencies, without adding the VCVars one. conanbuild.bat basically calls conanbuildenv-release-x86_64.bat and vcvars. You could run self.run("....", env=["conanbuildenv-release-x86_64", "conanrun"]) (you would need to parametrize the release-x86_64 part). That way, the conanbuild.bat will only inject the cmake exe path into the PATH env-var.

Do you have any idea when the runtime deployer is going to be released ?

It is intended to add it, but haven't started, so there is no expected date for this to be released. It shouldn't be a blocker if you can use your own, but I'll try to push this when possible.

We have many different projects that consume various number of our own packages, currently we are in the process of breaking some very big and monolith packages into smaller pieces, so nowadays I guess we are speaking on ~packages for the deepest tree, but it's going to grow to around 40.

Just in case, make sure that packages that do not actually package shared libraries do not define cpp_info.bindirs = ["bin"], that would add length unnecessarily.

But yes, 40 would be problematic. Having the cache close to the C:/ will mean paths around 50 characters, and 40x50 = 2000, and with the typical system Path length, that would be a problem.

[memsharded]

the runtime deployer was added some versions ago, still experimental but:

-d DEPLOYER, --deployer DEPLOYER
                        Deploy using the provided deployer to the output folder. Built-in deployers: 'full_deploy', 'direct_deploy', 'runtime_deploy'

can be used in conan install

Have you settled down with any approach for this?

[memsharded]

Hi @mikirothman

Any further question or issue here? Did you finally try the deployers? Thanks for your feedback.

[AbrilRBS]

Closing now as we didn't hear back from you, please do feel free to reopen/create a new issue if you have any other questions, thanks!