Installing CuPy via Anaconda breaks GeNN

[neworderofjamie]

When you install e.g. CuPy using Anaconda, it installs a special version of the CUDA runtime as an anaconda packages and sets CUDA_PATH to point to it. I guess this is cool because you can install a desired CUDA version in userland but bad because CUDA_PATH looks like c:\Users\USER\Anaconda3 which cannot be parsed by this regex used by the MSBuild build system to extract the CUDA version:

<CudaVersion>$([System.Text.RegularExpressions.Regex]::Match($(CUDA_PATH), "\\\v([0-9.]+)$").Groups[1].Value)</CudaVersion>

The result of this is then used to find the CUDA build extension:

<Import Project="$(VCTargetsPath)\BuildCustomizations\CUDA $(CudaVersion).props" />

We could find the CUDA version some other way and do the same thing:

• Standard CUDA installs come with a version.json which we could parse but it seems doubtful the CUDA Anaconda package includes this as CHECK
• Get the version of a dll
• Something else

However, doing this would still require that you have installed CUDA manually and configured it for the correct version of Visual Studio so, maybe it would be better to use an alternative mechanism:

• Maybe the Anaconda package includes the build props in extras\visual_studio_integration\ like standard CUDA installs CHECK
• We could invoke NVCC directly from MSBuild and thus not require the CUDA extensions

Finally, what happens on Linux when you install CUDA like this?

[neworderofjamie]

It seems like CuPY itself is the problem not the CUDA toolkit - needs more experimentation

[FabianSchubert]

I can confirm that installing CuPy using Anaconda breaks GeNN on Linux as well, in that it claims that CUDA_PATH was not set when attempting to build a model, even though the path variable is set correctly.

Calling genn_model.build() leads to an error in line 153 in CUDABackend.py:

return _CUDABackend.create_backend(model, outputPath, backendLevel, preferences)
RuntimeError: CUDA_PATH environment variable not set -

[FabianSchubert]

More specifically, it happens to be the case that activating a conda environment erases the $CUDA_PATH variable in the current shell session. This problem remains after calling conda deactivate.

[neworderofjamie]

On Windows at least, I have found that the anaconda environment copies CUDA_PATH into CONDA_CUPY_CUDA_PATH when activating the environment. At least a workaround, we could look at this too.