scala – 将本机系统库与SBT集成

正如你已经提到的，搞乱java.library.path在配置SBT和Eclipse方面可能很讨厌，我不认为可以自动为可执行jar执行。

所以离开System.load。在编写自己的本地库方面，您可以做的是：

>创建一个SBT任务，编译您的本地源(使用javah和gcc)，生成的.so文件和它依赖的任何.so文件，将它们放在目标目录中的jar(作为资源)中，并添加路径到jar到unmanagedJars在Compile。
>创建Scala方法以加载库。而不是调用System.loadLibrary，它将使用Class.getResourceAsStream读取库，File.createTempFile将它写在文件系统上的某个地方，而System.load将其加载到JVM。
>现在，不是像以前一样调用System.loadLibrary，而是调用MyClasspathJniLoader.loadLibrary。

这将与SBT运行，Eclipse和可执行jar无任何额外的配置(虽然我不知道proguard知道包括哪些资源)。

现在对于已经写的第三方本地库，其中一些像jblas已经使用这种“胖罐子”的方法。如果他们希望你设置java.library.path然后他们调用System.loadLibrary时，他们感觉像它，你需要做一些魔法，使这项工作。

我没有尝试这个，但这个解决方案可能工作：

>使用类似的SBT任务将所有的库在其本地路径上放入一个jar作为资源，并将该jar放在clsaspath上。
>创建一个Scala方法，该方法接受一个函数和一个库名称列表，创建一个临时目录，将这些库从jar的资源读入临时目录中的文件，将临时目录添加到java.library.path中，调用传入的函数，最后将java.library.path恢复到之前的状态。
>第一次调用本地库时(当它可能静态初始化并进行System.loadLibrary调用时)，在方法中使用要加载的库列表包装该特定调用。这样，当它调用System.loadLibrary，它的所有库将在java.library.path，并将成功加载。

显然，这是恼人的，因为你必须手动初始化第三方库之前使用它，但似乎更可行包装所有的初始化点(你的主要功能和测试初始化??)比它得到所有的工具来设置java .library.path正确。如果你已经在第三方库上面有了自己的抽象层，那么它可能会更简单，所以你只需要一个初始化点。

如果这看起来像一个现实的解决方案，我可以添加更多的细节SBT任务或Scala包装器方法，如果你困惑。