-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add spack package #486
Add spack package #486
Conversation
Ahh yeah, |
4b3ac3a
to
3282dbb
Compare
Hmm, spack's googletest package installs headers and builds libraries → should I modify the Makefiles to just link against |
3282dbb
to
65b2607
Compare
Ahh damn, I had no idea google test had done that - when we first started using it I'm sure there recommendation was just to build and link the C++ source. I'd need to modify the Jenkinsfile to checkout master of google test and build it with cmake rather than just extracting the release tar ball which sounds like a task for another day tbh. I'll add issues to do that and make |
65b2607
to
512c7d9
Compare
Sounds good, thx! (And I implemented some "patching" for the meantime… :)) |
dbd33ef
to
848de21
Compare
38d72c4
to
1c8da78
Compare
After patching some more gtest things → |
1c8da78
to
5d9b275
Compare
the |
Sure :)…
btw. |
7cfabb6
to
e34c9c3
Compare
Thanks! I don't think CUDA passthrough has made it to any but the most bleeding edge Windows update streams so we have plenty of native Windows users (myself included) |
It should have been a symlink, I guess…
e34c9c3
to
ed7ae0b
Compare
Hmm, no windows support in spack yet… cf. spack/spack#9323 BTW. I fixed another issue: I believe |
And one more missing Makefile added… |
There are still a few of those |
Is there anything left that I should modify/fix/add? |
That all looks good to me - when we update to building gtest as a library, a lot of the hacks will disappear. One small question - do the |
Shit! Your fixing of symlinks has uncovered an AMD-specific OpenCL issue 🤮 |
No, it's all ranged versions (cf. https://spack.readthedocs.io/en/latest/basic_usage.html#version-specifier for details) → anything above (and including) Python 3.8.0, numpy >= 1.17.0 and >= 1.0.0 for importlib metadata thingy… the other dependencies are unspecified in terms of versions.
But that would avoid a spack-tracked software environment, i.e. in the general case this will lead to conflicting package specifications ⇒ that's the main reason for using spack → tracking ALL dependencies in a DAG and solving the requirements to arrive at a valid "concretization" of this graph. |
Ok, it's not clear to me why Jenkins is still saying this failed as it did not. |
|
||
// CLI11 includes | ||
-#include "../../include/genn/third_party/CLI11.hpp" | ||
+#include "genn/third_party/CLI11.hpp" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What exactly does this patch aim to fix?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@muffgaga - am just trying to tidy up before releasing 4.7.0 - I'd like to get this merged but I still don't quite understand why this is being patched
@neworderofjamie That's what I used to get GeNN installed via spack. We probably need some more testing… should I just try to run the
run_tests.sh
? I tried, and there's an additional dependency on lcov and gtest that I need to add it seems… but also some other include-path(maybe?)-related fails. And another problem is that the test takes quite long (compared to normal install tests)… and it's not reporting errors via a non-zero exit code ;).@healther Maybe you can also have a short look and provide some comments? I also plan to add this to upstream spack.