Wayne, sorry for top posting, using a limited device.

If FFI is aiming 1.9.2 or bigger, then the rubygem spec needs to be
tweaked to reflect that. I'm not against of ditching 1.8.x support,
but just want to reduce painful support issues for users still using
1.8.x


On 12/1/10, Wayne Meissner <wmeissner@gmail.com> wrote:

> On 2 December 2010 03:38, Jon <jon.forums@gmail.com> wrote:

>> Understood and I think your darwinistic focus is a good choice. If the
>> mingw32 (fat or otherwise) binary is truly valued, patches should
>> eventually flow, right? ;)

>
> Thats the theory I'm working under.
>

>>
>> I see what you mean re: Function.c.  Doing a "gem install ffi
>> --platform=ruby" using DevKit on 1.9.3dev errors out on
>> 'async_cb_{mutex,cond,call,wait}' and then 'struct gvl_callback'.  I want
>> to look into it.

>
> It should be pretty straightforward to convert from pthread
> conditionals and mutexes to the win32 equivalents.  The code isn't
> doing a lot of tricky stuff, just putting stuff onto a queue,
> signalling the queue processor and waiting for notification that the
> task has completed.
>

>>
>> As your focus appears to be 1.9.2+, are you thinking that future mingw32
>> binary gems will _not_ be fat?

>
> It would be 1.9.2+ only.  The main reason to ditch 1.8.x, is the lack
> of threading support - specifically, the ability to detect non-ruby
> threads trying to call back up into ruby, and handle that situation
> sanely.  This causes all sorts of strange errors.  FFI should
> technically build and work fine on 1.8.x apart from that.
>

-- 
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