vscode-cmake-tools
vscode-cmake-tools copied to clipboard
documentation for anaconda environment setup?
I have a project using both python and C++. The C++ compilation is managed by cmake. I have already selected the pyton interpreter of my conda environment, but this vscode-cmake-tools do not recognize the selected environment. It would be nice to support this. Some documentation of how to setup conda environment would be great too.
This is an example project: https://github.com/pybind/cmake_example
@jingpengw - did you find a workaround for this? I am facing the same problem.
I believe I have a similar issue, I have conan configured in a conda environment that I'm trying to use within a cmake project inside Visual Studio Code running on Windows 10.
When I run the cmake command from a command line I need to conda activate <environment>
prior to running cmake so that conan will correctly import. When running the cmake configure from within vscode I get a DLL load failure for _sqlite3, because the DLL cannot be found.
I am assuming the failure occurs because the appropriate directory paths are not being added to the PATH environment - this is normally done during the conda activate.
vscode does run the appropriate conda activate when I open a terminal from within vscode based on the chosen python interpreter being selected within.
My cmake configuration is based on https://github.com/lefticus/cpp_starter_project
@KevinJW, try to run the conda activate command from a script that you invoke via environmentSetupScript in a your kit. When a kit is selected, that script is run and any modifications of the environment are persisted in the VSCode instance (configure, build and test will benefit from these modifications). If you don't have a kit (you use "unspecified"), you still need a way to hook this script and you can write one which doesn't mention compilers or generators or anything, except this script and then make sure you select this kit. If you need help with this let us know. Also, you can open VSCode from an environment where you ran this already and any environment variables will be inherited.
Please let us know how this works and if anything else is blocking you or I missed some aspects of your scenario we'll be here to help further.
@andreeis Sorry if I have this wrong, but are you saying that the environmentSetupScript entry goes in the cmake-tools-kits.json ? I couldn't find that documented and it doesn't come up in the completion list, when I add a line similar to this:
{
"name": "Visual Studio Build Tools 2017 Release - amd64",
"visualStudio": "5a094979",
"visualStudioArchitecture": "x64",
"preferredGenerator": {
"name": "Visual Studio 15 2017",
"platform": "x64",
"toolset": "host=x64"
},
"environmentSetupScript": "c:\\source\\conda_setup.bat"
},
Where the bat file contains:
echo conda activate base
conda activate base
It doesn't appear to execute nor error or anything, having tried switching Kits and build variant, though it looks like this gets over written if I reload/restart vscode, or at least something removed my lines when I was experimenting.
Starting vscode from within an environment with the appropriate activation run prior, does appear to work
Kevin
We are behind with updating our documentation with a few things, environmentSetupScript included. We will get to explain that eventually. You wrote correctly. I don't remember if our logging mentions that or not, but are you able to see the effects of it as if it was run? You need to select the kit that defines that script path (or reload your project in VSCode after adding that keyword in cmake-tools-kits.json, within the scope of the kit that you selected, double check it's not a different kit you modified). About overwriting your environmentSetupScript, a kits rescan may have done this but I wonder what could have triggered such rescan. It is done when the cmake-tools-kits.json is empy or when we ship a new extension release (that introduces a breaking change in the kits specification).
Set "cmake.loggingLevel" to "debug" in your .vscode/settings.json and reload your project again (after you added environmentSetupScript back in). Let's see what triggers a kits rescan. And let's see if the script is run at all.
Facing the same issue now. I have tried a similar setup as @KevinJW and can confirm that the conda activate
in the script specified as environmentSetupScript
does not seem to have any effect. An echo
from the script also does not appear to be captured (which is I guess what makes it appear that the script is not executed at all for @KevinJW), however I could confirm that the script is actually executed by having it write to a file (i.e., echo "activate! > some_file
).
Looking at the logs, it seems that the conda installation is not included in PATH when the script is called, meanning that conda activate
will not work; afaik conda installation is usually added to PATH by a section in the users .bashrc, so I guess that's not evaluated here? That said, the following content of the environmentSetupScript
now works for me (on a Kubuntu system)
#!/bin/bash
source <anaconda_install_base_path>/etc/profile.d/conda.sh
conda activate <your_env_name>
Since the cmake executable is part of the conda environment (due to a quite outdated cmake version on the system that I cannot easily update), I also had to set cmake.cmakePath
in the settings (and restart vscode for that to take effect) - it'd be great if the cmake-tools would pick up the cmake binary according to PATH after executing the environmentSetupScript
, which apparently is not the case right now.
Thank you @lumip for the scripts. Worked wonderfully. Only downside I found is that environmentSetupScript
doesn't allow you to pass arguments, so I needed a new script for each conda environment. After poking around in the code a bit, I came up with a one-liner that can be specified in the kit file:
"environmentSetupScript": "<anaconda_install_base_path>/etc/profile.d/conda.sh\" ; conda activate <your_env_name>\"",
Just wanted to share if others come across this issue. It's a bit of a hack but it works well for me but may not work in future versions. The \"
are very important and intentionally placed to allow multiple commands to be executed. This works because cmake tools generates a script that looks like:
source "${environmentSetupScript}"
printenv
Using the above value for environmentSetupScript
, the script turns it into:
source "<anaconda_install_base_path>/etc/profile.d/conda.sh" ; conda activate <your_env_name>""
printenv
I like the Bobby Tables approach. 😄 We may not be able to guarantee that it works like this forever, but we're not likely to change this code in the near future.
@bobbrow I was looking at switching from using Kits to using the new Cmake Preset functionality. However, it seems that you have to use either presets or kits, not both in this extension. This would prevent me from sourcing the conda environment that I am doing above.
Is there any plan to support conda environments with this extension? Or possibly some other setting similar to environmentSetupScript
option that would allow me to use Presets and Conda environments at the same time?
I can get by with kits for now, but Presets have some very attractive features that would improve my teams workflows (namely the CMakePresets.json
for shared settings and CMakeUserPresets.json
for individual user settings)
Before you open your C/C++ project, activate your conda env first:
conda activate xxx
then on the current terminal session, you can open your project via code .
and it works for me.
The conda environment can't be activated again if using environmentSetupScript
, the only way to activate another conda env for other folders is to kill the vscode-server
and open the folder again.
If it's about finding the correct python I was able to work around this with a CMAKE argument: -DPYTHON_EXECUTABLE=/home/user/anaconda3/envs/model/bin/python3
. At least allows the configure to find the correct libs from VS Code for me.
I cannot make mamba activate
work although apparently a shell file is sourced, and I cannot make it output any errors. It is really sad that this extension does not allow to use environment defined by mamba/conda environment.
I use vscode via SSH Remote very often, and then this extension does not help as sometimes it eagerly breaks the built that I do in a separate terminal.
Before you open your C/C++ project, activate your conda env first:
conda activate xxx
then on the current terminal session, you can open your project via
code .
and it works for me.
This approach works fine when running locally. Is there a way do the same when connecting remotely via SSH? I was trying to use a RemoteCommand in my ssh config, and although I think I have made all the right changes in remote.SSH settings the connection fails.