Yes, but also exposes issues and clashes if some gem bundles a dll like OpenSSL which proven to clash with the openssl bindings. There is a example of that scenario when running postgresql adapters, the bundled openssl dll and trying to require 'openssl' library.
I saw that Ruby C openssl built/linked to a older version of openssl (the one in ruby/bin) produce some errors when postgresql bundled dlls precede in the PATH.
If the dlls have the same name, but are different versions, and both are used in the same process, then yes you'd have an issue for that process. But in the copying solution you have an even worse problem - you would have permanently broken one of the GEMS forever by overwriting its dll. So I still see the copying solution is higher risk. I agree there is no great solution here though.
Here is another example. Libxml2.dll requires libiconv. Ruby already has one, but libxml is using a newer one. Different files name for now though, so no conflict. But I'd hate to intall libxml and have it overwrite Ruby's iconv by mistake.
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.
That means make RubyGems Ruby/DL dependant and include the SetDllDirectory API. I'm not against that, but we need to know how deep those modifications go.
Actually this works (at least on Windows): ENV['PATH'] += 'path to library'So actually you don't need the dependency on SetDllDirectory. But yes, point taken. If you need to use SetDllDirectory, there would be a gem dependency on Win32API.
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.Is better we find sooner a name to make them fit properly sooner than later :-)
Yes :)I'd have 2 things, executables and libraries. But if we decide to combine them, then your suggestion of binaries is good.
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.SetDllDirectory ? or you're talking about ENV['PATH'] alteration in this case?
Oh, sorry. I was thinking of the case that files added to spec.libaries are copied to ruby/bin. Or if we did the PATH thing, then ENV['PATH']
But that raises a good point. Whether we copy the files or manipulate the path, from a GEM developer point of view they will still be specified in the same way (spec.libraries, spec.binaries, spec.exetuables, or whatever we call them). Note that here is an example of why having spec.executable and spec.libraries is better than just spec.binaries. In the first case, you have to copy executables to ruby/bin but in the second you do not.
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.I'll love to heard back from Eric and other RubyGems developers about this.
Definitely.
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.We agree :-PSomething similar is what I do for mongrel_service.Services are a bit different, in that you need admin rights to install.Oh, I was not talking about installing services, I was talking about mongrel_service use a small script to copy mongrel_service executable into ruby/bin directory.
Ah, I see.
(I need to improve my english)
Your English seems great to me :) Thanks for all your ideas and feedback, it really helps. Charlie
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
