On Nov 10, 2007 8:05 AM, Trans <transfire at gmail.com> wrote:
> On Nov 9, 2007 11:12 PM, Luis Lavena <luislavena at gmail.com> wrote:
> >
> > I guess that will work... but must validate my idea later (with a
> > windows machine handy) :)
>> If you read my prior poists, you would know that's exactly what I did
> with the current TMail gem. And in no uncertain terms it is a complete
> *hack*. Nor is it a perfect solution. If nmake or make is not present
> it still bombs.
>
I was lazy enough to look the previous post of this thread, sorry :-)
> I would like to know the RubyGems official policy on supporting a
> pure-ruby version of a library that can also have platform extensions.
> As far as I can tell, there is no clear policy for this.
I see this somehow different:
<gemname> is marked ::RUBY platform, and don't bundle the native
extension (because it can run without it).
<gemname>_native or _c or _extension is just the extension compiled
for the platform, or marked ::RUBY to fire the compile process.
in <gemname> you try rescue the presence of 'gemname_native', and also
add that in the summary of the gem:
"add gemname_native to get a boost of performance in your platform --
remember that you need a compiler in case no pre-built gem is
available".
Making this clear to the end-user will reduce the questions about it.
Still, there are gems that cannot revert to pure-ruby solution for the
missing extension, and is good they fail if no compiler is available.
Trans, these are my POV of the situation, and I'm not trying to
convince you is the right way of doing it :-)
Regards,
--
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi