Ich arbeitete an einem Projekt, das das Laden nativer Bibliotheken erforderte, und bisher war die gesamte Entwicklung auf Linux beschränkt. Um mein Projekt zu run
, konnte ich einfach Forking aktivieren und java.library.path
wie folgt ändern:SBT: Plattformübergreifende Möglichkeit, java.library.path zu setzen?
javaOptions in run += "-Djava.library.path=some/common/path:lib/native/linux"
Meine Frage ist: Wie kann ich das gleiche in einer plattformübergreifende Art und Weise zu tun, so dass ich meine Build teilen können. sbt mit einem Windows-basierten Entwickler. Es gibt vor allem drei Dinge, die ich nicht so weit heraus:
- Ich weiß, dass SBT plattformunabhängige Pfade wie
"dir1"/"dir2"
konstruieren können, aber ich bin mir nicht bewusst eine plattformübergreifende Art und Weise zu verbinden mehrere Pfade (seit es ist:
unter Linux und;
unter Windows). - Ist es möglich, abhängig von der Plattform entweder
lib/native/linux
oderlib/native/windows
anzufügen? - Mein Ansatz oben überschreibt
java.library.path
- ist es möglich, stattdessen anzuhängen?
Das sieht gut aus. Ich habe vergessen zu erwähnen, dass ich immer noch SBT 0.12 benutze und generell auf eine versionsunabhängige Lösung gehofft habe. Aber ich denke, diese Idee funktioniert auch in 0.12. Ich habe es immer noch schwer, die '/' -Syntax von SBT zu verwenden, da es keine implizite Konvertierung von String in (ich denke) Datei gibt. Aber natürlich gibt es immer die Möglichkeit, es manuell mit 'separatorChar' zu machen. Und zu Debugging-Zwecken: Gibt es eine Idee, warum 'show java-options' immer nur' List() 'zurückgibt? – bluenote10
Ja, das sollte in 0.12 funktionieren. Außer IIRC verwendet es Scala 2.9 für die Build-Konfiguration, daher sollte die String-Interpolation durch '+' ersetzt werden. Für die letzte Frage, ich weiß es nicht. Vielleicht fragen Sie es separat? –
Was ist mit 'System.getProperty (" java.library.path ")' und machen Sie die Verkettung selbst? –