On Nov 10, 2007 8:05 AM, Trans <[EMAIL PROTECTED]> wrote: > On Nov 9, 2007 11:12 PM, Luis Lavena <[EMAIL PROTECTED]> 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 _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
