How to use anaconda (miniconda3) c++ development environments with CLion ?



To address multiplatform development, and to take advantage of community build packages, I'm currently using anaconda (miniconda3) environments, for C++ development, that includes cmake, make, gcc and other development tools.

I'd like to know how can I use, anaconda environments with CLion on the build process.

Currently I've defined a toolchain, to point to the cmake executable under my anaconda development environment, also added the python interpreter as an anaconda environment (same as PyCharm).

Still after those settings, the cmake fails to find libraries that are defined in the conda environment.

The same does not occur when developing under console with the conda environment activate, cmake successfully configures and code successfully compiles.

Is there a way to use the anaconda environment in the cmake configure and build process?


Hi Mario!

May be the same methods as for ROS development in CLion will help -


Hello! Have there been any updates concerning this issue? Or is there a relevant CLion YouTrack issue to refer to? Launching CLion from within an activated Conda environment works as a workaround. However, it's inconvenient to keep track of and launch each project with its corresponding environment outside of the project, rather than having it be part of the project configuration.


Hi Greg Olmschenk!

In CLion 2021.3 EAP we added the ability to initialize toolchain environment via script - Maybe this feature will help in your scenario?


Hi Anna Falevskaya. Yes, this works. I look forward to seeing it in the stable version. Thank you!


Hi Anna Falevskaya

I still can't add conda env before compiling in CLion 2021.3 EAP. Could you have a detailed blog for this?




Hi Wbo4958!

We have a blog post and a web help article about the new feature mentioned in previous comments.


Writing an issue I had here, in case anyone has the same problem.

I wanted to activate a specific conda environment so that the CMAKE function find_package(Python 3 COMPONENTS Interpreter Development REQUIRED) would find the correct python environment where a header package called pybind11 was located. Then find_package(pybind11 CONFIG REQUIRED) works correctly.

Assuming the conda environment is called myEnv, follow the web help article Anna mentioned and for the File add a batch file (called setup.bat, for example)  with the following lines:


CALL \path\to\anaconda\or\miniconda\folder\Scripts\activate

CALL conda activate myEnv

Notes: in CLion Settings > Build, Execution, Deployment > Toolchains, I had to configure Visual Studio to build in amd64 architecture, which is how my Python was compiled (x64). The default was x86 and this was causing errors.


For me this feature somehow does not work in CLion Build #CL-231.9161.40, built on June 20, 2023.

I created a very simple environment file, where I set variables PATH and MYPATH, and they both are empty when CMake is running (print them in CMake via `cmake_print_variables`). I can confirm that the environment file is called as I have there `echo 123 > $HOME/log.log` and after $HOME/log.log has indeed '123' in it. However the variables themselves are not available in CMake build process.


Dmitry Kabanov please add message("$ENV{PATH}") and message("$ENV{MYPATH}") to CMakeLists.txt, and then do `Tools | CMake | Reset Cache and Reload Project`. What result do you get in the CMake tool window?


Anna Falevskaya, yes, these lines show correct results for a simple `env` file like this:

export MYPATH=something

Thank you. However, the problem with sourcing conda environment is still there for me.

My actual env file sets conda environment (well, using mamba instead of conda actually) and look like this:


echo "Start" > $HOME/log.log
echo Shell = $SHELL >> $HOME/log.log
which mamba >> $HOME/log.log
if ! command -v mamba >/dev/null 2>&1; then
echo "Command mamba not found" >> $HOME/log.log
if [ -f "/home/dima/sw/mambaforge/etc/profile.d/" ]; then
source "/home/dima/sw/mambaforge/etc/profile.d/"
echo "Sourcing" >> $HOME/log.log
echo $(which mamba) >> $HOME/log.log
mamba list >> $HOME/log.log || echo "mamba list failed"
mamba activate um01-open-interfaces 2>&1 >> $HOME/log.log || echo "mamba activate failed" >> $HOME/log.log

echo CONDA_PREFIX = ${CONDA_PREFIX} >> $HOME/log.log
echo python = $(which python) >> $HOME/log.log


When I source it into shell inside a terminal application:

$ source ~/wrk/um01-open-interfaces/autoenv-enter.zsh

I get this log file (ommitted in the middle):


Shell = /bin/zsh
mamba () {
    \local cmd="${1-__missing__}"
    case "$cmd" in
        (activate | deactivate) __conda_activate "$@" ;;
        (install | update | upgrade | remove | uninstall) __mamba_exe "$@" || \return
            __conda_reactivate ;;
        (*) __mamba_exe "$@" ;;

# packages in environment at /home/dima/sw/mambaforge/envs/um01-open-interfaces:
# Name                    Version                   Build  Channel
_libgcc_mutex             0.1                 conda_forge    conda-forge
... (many lines here)
zstd                      1.5.2                hfc55251_7    conda-forge
CONDA_PREFIX = /home/dima/sw/mambaforge/envs/um01-open-interfaces
python = /home/dima/sw/mambaforge/envs/um01-open-interfaces/bin/python


that is, it runs successfully and source conda environment.

In contrast, when I run CMake with this environment file inside CLion, the log look like this:


Shell = /bin/zsh
mamba not found
Command mamba not found
mamba () { \local cmd="${1-__missing__}" case "$cmd" in (activate | deactivate)
__conda_activate "$@" ;; (install | update | upgrade | remove | uninstall) __mam
ba_exe "$@" ||  eturn __conda_reactivate ;; (*) __mamba_exe "$@" ;; esac }
mamba activate failed
python = python not found


The shell (ZSH) is the same that I use in terminal. However, I see that there is a problem with the defitinion of the `mamba()` function: in the successful run inside a terminal app, mamba() definition has a line "\return __conda_reactivate" (mind the backslash). Inside CLion, somehow "\return" becomes "eturn" as if "\r" is considered as a CR (curret return) control character. Maybe also whitespace plays role, I am not sure.

CLion "About" page:

CLion 2023.1.4
Build #CL-231.9161.40, built on June 20, 2023
Licensed to Dmitry Kabanov
Subscription is active until August 9, 2023.
Evaluation purpose only.
Runtime version: 17.0.7+10-b829.16 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Linux 5.19.0-46-generic
GC: G1 Young Generation, G1 Old Generation
Memory: 2000M
Cores: 8

Current Desktop: ubuntu:GNOME


Evgenii Novozhilov good to know, thanks. Although I am not quite convinced, as the issue mentions msys2 and zsh, that is Windows, while I am working under Ubuntu.