search

jcuda / jcuda-main

Summarizes the main JCuda libraries
MIT License
99 stars 20 forks source link

Failure on SBT #22

Open ctongfei opened 6 years ago

ctongfei commented 6 years ago

When using JCuda in SBT (build tool for Scala), it results in a ResolveException:

[warn]  [FAILED     ] org.jcuda#jcuda-natives;0.8.0!jcuda-natives.jar:  (0ms)
[warn] ==== public: tried
[warn]   https://repo1.maven.org/maven2/org/jcuda/jcuda-natives/0.8.0/jcuda-natives-0.8.0-${jcuda.os}-${jcuda.arch}.jar

The problem is that Apache Ivy, the resolver used by SBT, does not expand pom macros such as ${jcuda.os} or ${jcuda.arch} (as is reported in https://github.com/sbt/sbt/issues/2666).

Could the JCuda core jcuda be changed to include one jcuda-core (that does not depend on anything) and a dependency on native libraries?

So in this way I can do jcuda-core and an arbitrary jcuda-native-apple-x86_64 (without using the auto-platform-resolving jcuda) to avoid the SBT problem.

jcuda commented 6 years ago

That vaguely sounds similar to the issue reported for Gradle at https://github.com/jcuda/jcuda-main/issues/16#issuecomment-297356346 : There, the respective ${jcuda.os} and ${jcuda.arch} properties had not been resolved. The solution there seemed to be to resolve them in the build file.

I'm not familiar enough with SBT to know the most appropriate solution here, and did not yet fully understand your proposed solution. It sounds like you wanted to create a jcuda-core project, where you manually edit the POM to resolve the platform-specific binaries. However, the (Java) JCuda POM already depends on jcuda-natives. The ${jcuda.os} and ${jcuda.arch} are supposed to be resolved via the parent POM.

The fact that SBT does not resolve (or properly "forward") these properties seems to be an issue. During a quick websearch, I found https://stackoverflow.com/q/46763741/3182664 , which seems to be exactly the same problem.

Is the workaround that is proposed there a viable one? (I.e. is it reasonable, and does it work for you?) Or do you think that this could be solved more elegantly?

gnuzzz commented 6 years ago

as a fast workaround - you can run sbt with JVM parameters -Djcuda.os=linux -Djcuda.arch=x86_64

ctongfei commented 6 years ago

Thanks. It works for me.

jcuda commented 6 years ago

Thanks for figuring this out.

I'll reopen this issue, but just as a reminder for me to add a note about this at the https://github.com/jcuda/jcuda-main/blob/master/BUILDING.md page.

EDIT: Although it should probably go into https://github.com/jcuda/jcuda-main/blob/master/USAGE.md , alongside the info about Gradle...?!