Dummy build for macOS?

[blueberry]

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?

[jcuda]

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 UnsupportedOperationException("You're on MacOS, sorry"). That wouldn't make sense.

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 jcuda-natives-11.0.0-apple-x86_64.jar. These are technically valid artifacts for maven.

Trying to load the native library on Mac would then cause an UnsatisfiedLinkError, but of course, if we do this, I'd do a check before the library is loaded - basically, somewhere where the LibUtils class is used, roughly as in

if (LibUtilsEx.weAreOnMac()) throw new CudaException("MacOS does not support CUDA (or vice versa?)");
else LibUtils.load(...);

just to make clear that this wouldn't be one of the "usual" UnsatisfiedLinkErrors that are nowadays only caused by having the wrong CUDA version installed.

[blueberry]

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.

[jcuda]

Sure, this makes sense. You could try out whether mvn clean package generates the desired empty JARs on Mac. (I could probably also do this, by manually overriding the properties that are set automatically by Maven, if desired). I could then add the small LibUtils check for the next release.

[jcuda]

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: https://github.com/jcuda/jcuda/commit/9f30335319361a602938e462f696022c1d295b11#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 mvn-clean-package on MacOS creates the desired (empty!) ...natives.jar files (or whether the fact that they are empty causes any trouble). If this is the case, then this might actually play out well: The empty JARs would appear to be valid artifacts for Maven during the build, and only at runtime, it would say that this CUDA version is not available on MacOS.