On Mon, Feb 2, 2009 at 12:48 PM, Berger, Daniel <daniel.ber...@qwest.com> wrote: > > >> -----Original Message----- >> From: rubygems-developers-boun...@rubyforge.org >> [mailto:rubygems-developers-boun...@rubyforge.org] On Behalf >> Of Luis Lavena >> Sent: Monday, February 02, 2009 3:35 AM >> To: rubygems-developers@rubyforge.org >> Subject: Re: [Rubygems-developers] Gem location and site arch >> directory >> >> On Tue, Jan 27, 2009 at 3:06 PM, Luis Lavena >> <luislav...@gmail.com> wrote: >> > On Tue, Jan 27, 2009 at 1:50 PM, Berger, Daniel >> <daniel.ber...@qwest.com> wrote: >> >> Hi, >> >> >> >> What do people think about RF Bug #14943. >> >> >> >> >> http://rubyforge.org/tracker/index.php?func=detail&aid=14943&group_id >> >> =126&atid=575 >> >> >> >> If I read it correctly, C extensions should be installed >> as "lib/i386-msvcr80/foo.so" instead of "lib/foo.so" (on >> Windows/VC8, for example). >> >> >> > >> > I believe it should be Gem::Platform.new(RUBY_PLATFORM).to_s or >> > Gem::Platform.local to match the gem filename signature, >> platform and >> > folder structure (is x86 instead of i386). >> > >> >> It seems reasonable to me, but I wanted to see what other >> people thought, and if there were any pitfalls to watch out >> for (beyond needing to modify the search path). >> >> >> > >> > I just commented on the Ticket, I kind of like it. >> > >> > This will workaround the issues I'm having with >> rake-compiler for copy >> > of binary .so file before packaging a new gem. >> > >> > Right now I don't see a problem in the long run with the proposed >> > solution (or a backward issue neither). >> > >> > This should be affecting the $LOAD_PATH during >> Gem::activate, correct? >> > (I'm not up to speed with RubyGems internals). >> > >> >> Regards, >> >> >> >> Dan >> >> >> > >> > Thank you Dan for bumping this. >> >> Daniel, >> >> Been thinking on that and playing (hacking) with this. >> >> I found a problem with this. >> >> As we said, we put the extension inside >> lib/architecture/ext.so, in that way rubygems adds the path >> for the specific gem. >> >> Now while this works for gems, will not work for you in development: >> >> lib/my_lib.rb: >> require 'my_ext' >> >> lib/x86-mingw32/my_ext.so >> >> The 'require' over there will not work for me doing "ruby >> -Ilib", so that render my specs or tests useless, since I >> need to add all the platform machinery in. >> >> Thoughts? This iwll be the first drawback. > > I guess I don't see the problem in practice. The 'lib/x86-mingw32/my_ext.so' > would not exist except and until it was installed as a gem. How people setup > their tests is up to them and seems, to me, to be orthogonal to this issue. >
Well, if I try to run the test of a installed gem that moved the extension to this directory then will be broken (gem test my-gem) -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry _______________________________________________ Rubygems-developers mailing list Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
