java.library.path clobbered by overtone dependency

[DoodleIncident]

Including Overtone in a project seems to do something strange to the java.library.path property. The reported value changes completely, and it is no longer configurable by :jvm-opts.

Reproduction steps (on Linux Mint):

lein new repro
cd repro
lein repl
=> (println (System/getProperty "java.library.path"))

This returns a nice long path that I can append to with the following:

:jvm-opts [~(str "-Djava.library.path=yada_yada/:" (System/getenv "LD_LIBRARY_PATH))]

Adding [overtone "0.9.1"] to :dependencies replaces this with a single path that I can't control:

/home/user/path/to/code/repro/target/native/linux/x86_64

I grepped "java.library.path", and overtone/script/java-env seems to be the culprit. Does anyone know the history of this line? Is there a neater way for it to accomplish its purpose?

[DoodleIncident]

Well then... from project.clj:

:jvm-opts ^:replace ~(jvm-opts))

I guess this may have something to do with it?

[rogerallen]

I believe the replacement comes from default Leiningen behavior based on this line in project.clj

:native-path "native"

If you comment that line out, (System/getProperty "java.library.path") prints out the full path.

I don't know why the default for Leiningen is to replace rather than prepend to the path, but this seems to be where to investigate further.

[DoodleIncident]

Sorry, that doesn't seem to be it. Here's the full code:

https://gist.github.com/DoodleIncident/8678033

The path output when I lein run this code doesn't have leap_lib in the path; if I switch the comments, lein clean, and lein run, it does.

[rogerallen]

When I referred to the :native-path tag in project.clj, I was referring to Overtone's project.clj, not your project.clj. The use of the :native-path by Overtone is causing the reset of the java.library.path, so when you add [overtone "0.9.1"] to your :dependencies, the path has been removed & you cannot see it anymore.

I'm really not sure what is "the right way" to fix this. You point out a legitimate issue, but it isn't obvious to me what should be done to remedy it. Should Overtone adjust it's project settings? Or is there a best-practice for Leiningen that properly works around this? I think I'll post something to Stack Overflow & see what the experts say. See http://stackoverflow.com/questions/21436744/best-practice-for-a-clojure-library-that-uses-native-libs

FWIW, when I was playing with the leap library, I created a library that had the libraries where leiningen expected them to be & uploaded it to clojars. See https://clojars.org/rogerallen/leaplib and https://clojars.org/rogerallen/leaplib-natives.

EDIT: added stackoverflow pointer

[DoodleIncident]

You're completely right, sorry for misunderstanding.

I actually came across your leaplib-natives clojar and managed to roll my own that included Linux dependencies earlier, so that's all working. Somehow I didn't make the connection that depending on leaplib would fix the issue until just now, though.

Thanks for the help! Lein is an awesome tool, but it really gets confusing once you start using multiple dependencies with their own project.clj's. I'll just use clojars at the top level to get around that for now.

[rogerallen]

Well I've apparently stumped StackOverflow so I went back and tried again to figure this out. I think I have a workaround, but it isn't a final fix. To do any better, AFAIK we'll need to get Leinigen to change. Please give this a try and let me know if this works.

I created a subdir of the project called leaplib. In there I put LeapJava.jar and in proper subdirectories, I put the native libs. (for me that's leaplib/macosx/x86_64/libLeap.dylib and leaplib/macosx/x86_64/libLeapJava.dylib)

In the project.clj, I put

  :resource-paths ["leaplib/LeapJava.jar"]
  :native-path "leaplib"

WIth this, (along with depending on overtone 0.9.1, I get expected results when doing all of these things...

user=>   (use 'overtone.live)
--> Loading Overtone...
--> Booting internal SuperCollider server...
Found 0 LADSPA plugins
Number of Devices: 7
   0 : "AirPlay"
   1 : "Built-in Microph"
   2 : "Built-in Input"
   3 : "Built-in Output"
   4 : "Soundflower (2ch)"
   5 : "Soundflower (64ch)"
   6 : "Aggregate Device"

"Built-in Microph" Input Device
   Streams: 1
      0  channels 2

"Built-in Output" Output Device
   Streams: 1
      0  channels 2

SC_AudioDriver: sample rate = 44100.000000, driver's block size = 512
--> Connecting to internal SuperCollider server...
--> Connection established

    _____                 __
   / __  /_  _____  _____/ /_____  ____  ___
  / / / / | / / _ \/ ___/ __/ __ \/ __ \/ _ \
 / /_/ /| |/ /  __/ /  / /_/ /_/ / / / /  __/
 \____/ |___/\___/_/   \__/\____/_/ /_/\___/

   Collaborative Programmable Music. v0.9.1


Hello Roger, may algorithmic beauty pour forth from your fingertips today.

nil
user=>   (import '(com.leapmotion.leap Controller))
com.leapmotion.leap.Controller
user=> (Controller.)
#<Controller com.leapmotion.leap.Controller@6d6058a1>
user=> (demo (sin-osc 500))
#<synth-node[loading]: user/audition-synth 31>

However, the downside is that after I run this, the Supercollider native dependencies are all stored in the native library paths under leaplib. I guess that isn't all that surprising, but it isn't very sanitary. A "lein clean" doesn't clean up after itself any longer.

p.s. I'm far from an expert in this and just trying to understand for my own satisfaction. If anyone has a better ideas bring 'em on...