Visual Studio Code - Activate Env before Debug - c++

Question

my current setup involves a boost-python module, that I wrote. To debug this module, I wrote a standalone C++ program that calls the python-script from within the C++ program.
int main()
{
try
{
PyImport_AppendInittab("oum_export", INIT_MODULE);
Py_Initialize();
PyObject *obj = Py_BuildValue("s", "/media/thomas/Data/seafile/Seafile/TUG/ILearnHeart/Anisotropic\\ Diffusion/python/oum_cpp_opt.py");
FILE *file = _Py_fopen_obj(obj, "r+");
if (file != NULL)
PyRun_SimpleFile(file, "D:/seafile/Seafile/TUG/ILearnHeart/Anisotropic Diffusion/python/oum_cpp_opt.py");
else
cout << "Script file to execute not found" << endl;
}
catch( p::error_already_set )
{
PyErr_Print();
}
Py_Finalize();
}
This should allow me to easily debug the callbacks made to the Python-modules, written in in C++. On invoking the vscode-debugger, the program crashes with the error
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: Unable to get the locale encoding
which is due to the fact that I'm not in the correct anaconda environment. How can I tell visual-studio code to enter the correct environment, before launching the gdb (i.e.: "source activate aniso_diff && gdb oum_export_test")?
Here's my current launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "oum_export_test",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}/build_linux",
"environment": [],
"externalConsole": true,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
"preLaunchTask": "build oum standalone"
}
]
}
I tried incorporating the activate command into the build preLaunchTask, but it seems vscode invokes a fresh shell for gdb.

Answer 1

This is probably a no-brainer for most of you, but I just figured out that the simplest solution is to simply activate your desired environment before invoking vscode on the same shell.