Hi Meikel, 2009/8/5 Meikel Brandmeyer <m...@kotka.de>: > > Well, this is independent of whether you have a C or Java > library. You can install each C library in its own directory > and tell the linker to look there. Then you have basically > a .jar like setup: If you don't tell the linker the right directory > the library "is not there". Similar you can declare "/usr/java/lib" > as your global directory and unzip each and every jar there. > Then configure your java launcher to add that directory to > the classpath and you have a setup, like the usual one > for C libraries. So this could even be system policy.
What I was trying to say is that in the native lib world there are standard locations that the linker has been configured to look at and as a result the user does not have to do anything. That's not the case in the Java world, where the user has to always set the classpath to point to libs that the app uses. My point is that life is easier for languages that use native libraries as extensions rather than Java, because things just work. Placing all my jar files in /usr/java/lib only solves the problem for me if I tell the JVM to look there, plus the JVM will not resolve jars unless I name each jar separately on the classpath, and finally putting all my jars in one directory will not help the users of my package since it's not a universal convention. In the Ruby world, Gems expect their native dependencies to be installed on the platform at Gem install time. The Gem install will fail if the native library is missing. It is up to the user to install the dependency before trying to install the Gem. The user is free to install the dependency in which ever manner he chooses: a source install, a binary install, install via another package manager (e.g. apt-get or MacPorts) etc. Drawing a parallel between Ruby and Clojure, a Clod package could expect jars to be available on the platform at package install time. It would be up to the user to install those jars before trying to install a Clod package. The user is free to install the jar either manually, with Ivy, or with Maven. The trick here is to make those jars available for each invocation of the JVM and I have no idea what the state of the art is here. You can always make it work with some shell scripts or a little bit of ELisp, but that doesn't really feel right to me. So why have all the other programming language package management systems like Ruby Gems, easy install, hackage decided not to worry about native dependencies? Is it simply because it would be difficult to do in a portable way covering all the various Linux systems, and OS X, and Windows? Or is there some other reason? And should the Clojure package manager punt in a similar fashion, i.e. simply let the user handle the Java dependencies? > All these setups can be done (more or less comfortable) > with today existing solutions for Java. Instead of re-inventing > those, it would be more useful to abstract away their specifics. > Create a meta-package manager which creates JVM, CLR > and whatever packages sitting on the existing infrastructure > for the respective platform. Agreed, we shouldn't reinvent the wheel for managing jar files when there are perfectly good solutions out there. AFAICT Meikel would like the package manager to automatically install jar dependencies, but it should use e.g. Ivy to do it? Sounds good to me, although I still feel that as a first step the package manager could simply worry about Clojure packages and expect the user to install dependencies either manually or with Ivy. A later iteration of the package manager could then include dependency URIs that result in third party package manager execution (e.g. Ivy), although it sounds like this will get ugly soon if we need to support more than a handful of underlying package managers with different package naming conventions etc. In any case, I agree with Sean, James should just go for it and we'll see how it works out. > Sincerely > Meikel -- ! Lauri --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
