[Rubygems-developers] Gem location and site arch directory

Berger, Daniel Daniel.Berger at qwest.com
Mon Feb 2 09:48:13 EST 2009


 

> -----Original Message-----
> From: rubygems-developers-bounces at rubyforge.org 
> [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf 
> Of Luis Lavena
> Sent: Monday, February 02, 2009 3:35 AM
> To: rubygems-developers at rubyforge.org
> Subject: Re: [Rubygems-developers] Gem location and site arch 
> directory
> 
> On Tue, Jan 27, 2009 at 3:06 PM, Luis Lavena 
> <luislavena at gmail.com> wrote:
> > On Tue, Jan 27, 2009 at 1:50 PM, Berger, Daniel 
> <Daniel.Berger at 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.

Regards,

Dan


More information about the Rubygems-developers mailing list