-
Notifications
You must be signed in to change notification settings - Fork 5
Test building improvements #9
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
base: master
Are you sure you want to change the base?
Conversation
I just discovered that this is incomplete, the |
Sure, just add me as reviewer when you're ready |
There, that should do it. |
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.
Changes look good. I can't remember what the reason was for the symlinks originally. So as long as the downstream codes are not affected (I guess they can use the older version which I'll be tagging in a bit then it should be fine).
I've been looking at the compiled-in kernels, and that seems to work fine with CUDA too once enabled. The users still pass a path, but that's just mapped to the right constant with the precompiled kernel data. If the user has a kernel of their own that they want to use, then they can still pass a path that will get used. I haven't actually tried to build any of the codes that use Sapporo against this yet. The new build system is pretty much there, and I'm adding some headers for the public API and a |
Here are some improvements for the build system of the tests:
The whole symlink thing is awkward anyway, and having the kernels in separate files is a bit tricky to manage if sapporo2 is packaged separately. It seems that for OpenCL, the kernels are converted to headers and included. The conversion is also done for CUDA, but the
.ptxh
file is currently unused. I'm going to try to make that work again, it's much easier than putting separate files into${PREFIX}/share/sapporo2/CUDA
and then trying to figure out where that is at runtime.Actually, I think it would be better if the user just specified which kind of integrator they wanted, rather than a path to a kernel file. Then the whole OpenCL-or-CUDA thing can be abstracted away, and the user just says "give me a 6th order integrator" with sapporo2 doing the rest. But I'm trying to do the minimum to get this packaged first, improvements and optimisations can come later if they seem urgent.