Support NMake build system for building generated code#700
Support NMake build system for building generated code#700neworderofjamie merged 15 commits intomasterfrom
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #700 +/- ##
==========================================
- Coverage 88.83% 88.43% -0.40%
==========================================
Files 106 107 +1
Lines 14749 14232 -517
==========================================
- Hits 13102 12586 -516
+ Misses 1647 1646 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…llback to CUDA_PATH\lib\x64 for manual installs, otherwise let linker use LIB if present
NMake (Windows): robust CUDA lib path resolution for Conda & system installs
tnowotny
left a comment
There was a problem hiding this comment.
I wish this could be a little less messy, but I appreciate the trade-off between the better build system (MSBuild) and the arguably more universal one (NMake) ... in terms of details, I need to trust you that this works.
|
It's a very annoying trade-off - I would just say to get rid of MSBuild for building generated code but NMake doesn't seem to track dependencies and that makes it way slower to build generated code |
I switched GeNN's Windows build system (both for building GeNN itself and generated code) from using NMake to MSBuild a long time ago as it's a nicer build system but, for building generated code, it has some disadvantages:
Therefore, in this PR, I have resurrected support for building generated CUDA code using NMAKE if the MSBuild plugins are not available. I have also tidied up a couple of other Windows build related things:
a. Decorating all the exported things with
__declspec(dllexport)when we build the generated code and__declspec(dllimport)when we link against it.b. Windows libraries needed to be generated in the same directory as the script rather than in the
_CODEdirectory which, in turn, also required them to have unique names. This is also no longer required and Windows now builds libraries called runner into the_CODEdirectory.$(CUDA_PATH)/x64/libso we have added a separateCUDA_LIBRARY_PATHenvironment variable (that defaults to$(CUDA_PATH)/x64/lib) but can be overridden. I think this will also help with other weird environments.