Skip to content

Improve deployment of native libraries #8

@javagl

Description

@javagl

(EDIT: This was supposed to be opened by jcuda - sorry, I was logged in with the wrong account)

This is a very broad issue, but it can hardly be broken down into individual steps

The current deployment of the native libraries has to be improved. Right now, the natives are deployed as real native libraries (.SO, .DLL and .DYLIB files). These are built with CMake, and declared as own artifacts with Maven, in their own POM. (See https://github.com/jcuda/jcuda/tree/master/JCudaDriverJNI for an example). The deployment could be simplified (and be more in line with the Maven philosophy) if the natives could be packed into JAR files, and unpacked and loaded at runtime. There are several (intedependent) tasks on the way to this goal:

  • It must be possible to load the natives from JAR files. The basic functionality for this has been hidden in the https://github.com/jcuda/jcuda/blob/master/JCudaJava/src/main/java/jcuda/LibUtils.java class for quite a while now, but has not officially been supported. There is an improved support for this in the JOCL LibUtils class ( https://github.com/gpu/JOCL/blob/master/src/main/java/org/jocl/LibUtils.java ), but unfortunately, these LibUtils classes have diverged. One step would be to update the LibUtils of JCuda so that it might eventually converge with the JOCL LibUtils (and maybe even become a standalone library in the future)
  • The native libraries must be versioned. When a native library is loaded from a JAR, then it is actually unpacked into the system "temp" directory, and loaded from there. Right now, the native libraries only have names like JCudaDriver-windows-86_64.dll, and thus, it would not be possible to have different versions of them on the same system. This could be solved by adding a version string, so that the library is named, for example, JCudaDriver-0.7.5c-windows-86_64.dll
  • The CMake files have to be updated to generate the natives, with version numbers, in a directory where they may be picked up by the Maven POM
  • The Maven POMs have to be updated to pack the natives into JAR files that are dedicated artifacts with appropriate classifiers, e.g. JCudaDriver-0.7.5c-windows-86_64.jar

I also opened a new thread in the forum for discussing the details, options, and the usual Maven loops that one has to jump through.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions