[Rubygems-developers] Gem location and site arch directory

Luis Lavena luislavena at gmail.com
Mon Feb 2 10:21:11 EST 2009


On Mon, Feb 2, 2009 at 12:48 PM, Berger, Daniel <Daniel.Berger at qwest.com> wrote:
>
>
>> -----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.
>

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


More information about the Rubygems-developers mailing list