Luis Lavena wrote:
Hmn, I was talking that One-Click Installer did that in the past since it bundled a lot of extensions and gems, but we are shifting to a gem-based design where RubyGems plan a important role. Manipulating the path? that means change code in RubyGems to take care of each gem that expose a "binary library"... I don't like the idea.
It has two big advantages. First, you don't have to copy all libraries to one directory. Second it solves the issue if 2 gems use different versions of the same dll (in the copying solution one gem will lose since its dll will be overwritten).
Remember, this path manipulation is only for the currently running process (not system wide) and is fully supported by the Windows api. Don't know about other OSes though, haven't looked.
What about #binaries? and we thread them different that executables (verbatim copy them instead of adding shebangs).I'd probably be more specific and define a new spec setting called "libraries" that means RubyGems will:But a library is also a ruby library, which doesn't apply. Is it a binary dependency of the extension bundled in the gem.
Yes. But there is a difference between a binary executable and a binary library. I think we would regret calling them the same thing, because they are not.
a) On installation copy the files marked "libraries" to ruby/bin b) On loading a gem, update the path to include the location of the library files (if any are set). So: Directory: libxml_ruby lib libxml2-2.dll GemSpec: spec.libraries << "lib/libxml2-2.dll" How does that sound?Hmn, that definetely add some platform specific code beyond what RubyGems should be doing... and from POV I don't like it so much.
Why is that platform specific code? Any file listed in libraries gets copied to ruby/bin.
Of course, you might not want that to happen on all platforms, but to solve that you just provide platform specific gems (which obviously you have to anyway if the GEM include binary files). For a Windows GEM you'd include the spec.libraries line, for other platform GEMS you would not.
And what should I do in the short term?Indicate your users to copy the dll or provide a RubyGems binary (minimal script) that performs the dll copy form that particular folder into ruby/bin (Gem.bindir)
Right - which is what we do now in the documentation. I think that's a bad solution and want to avoid it.
Something similar is what I do for mongrel_service.
Services are a bit different, in that you need admin rights to install. Charlie
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
