On Mon, Jul 21, 2008 at 9:23 PM, Charlie Savage <[EMAIL PROTECTED]> wrote: > > > 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). >
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. > 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. >>>> 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 :-) >>> 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. > SetDllDirectory ? or you're talking about ENV['PATH'] alteration in this case? > 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. > >>> 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. > We agree :-P >> >> Something 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. (I need to improve my english) Regards, -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
