-
Notifications
You must be signed in to change notification settings - Fork 20
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
Dummy build for macOS? #38
Comments
I'm not entirely sure what the benefit of that would be. Whatever program that is: The build will fail on Mac, and that's "fine", because it will not run on Mac. Otherwise, people might build it, think that everything is fine, and receive an error message when they try to start it. Did you receive any issue reports in one of your libraries about the missing MacOS support?) However, iff there is a scenario where this would be desirable, I wonder what the most appropriate way of solving this could be. Providing actual binaries would be difficult. These would have to be actual, valid native library files, where each function would have to bail out, maybe with an But if this only refers to the build process, then it might be "trivial", in some way: Doing the usual Maven build on MacOS without having created the native libraries should simply create empty JAR files, like Trying to load the native library on Mac would then cause an
just to make clear that this wouldn't be one of the "usual" |
Yes, it's practically the majority of issues: mac users would like to use Neanderthal (for non-cuda stuff), Neanderthal depends on CUDA, OpenCL, and MKL, CUDA is unavailable on mac, and their Maven build fails since there's no jcuda-native. The solution is to exclude jcuda-natives for macos, but unfortunately, if I do it in Neanderthal itself, it's not propagated to their projects; they have to do it explicitly. The solution is, perhaps, to provide empty jcuda-native. Unsatisfied link error would be OK, the message about macOS would be even better. |
Sure, this makes sense. |
I have (hopefully) "prepared" that, insofar that I have wrapped the loading of the actual libraries into a wrapper that checks whether the OS is "APPLE", and throws an exception if this is the case: jcuda/jcuda@9f30335#diff-9396c424167b800ceba0dcff25ab2c2a86d56130deb266c3445fd5295a656b09R59 I'm going out on a limb with that, because I have not yet tested whether this works as expected (but it is backward-compatible and an internal API, so this should be safe for now). The next thing to test would be whether an |
Hi @jcuda,
Currently, any Java code that depends on JCuda has to add exclusions for jcuda-native macOS classifiers; otherwise Maven can't find the artifacts and the build fails (on macOS). This is expected, due to CUDA 11+ not existing on macOS.
The problem is that this has to be done in user projects (classifier exclusions are not propagated) so it has to be explained to macOS users again and again that they have to do this in their own projects.
It came to my mind that an elegant solution could be that we provide dummy JCuda natives for macOS. They would not depend on CUDA 11, they would just do no-op or print a message that CUDA is not available on mac.
Is this possible (without hassle) with the current JCuda build tooling?
The text was updated successfully, but these errors were encountered: