Re: Non-gcc releases

[Ronald Oussoren <oussoren at cistron dot nl>]

On 25-mrt-04, at 21:58, Thomas Heller wrote:

> Tom Tromey <tromey@redhat.com> writes:
>
> > Etienne recently brought up the idea of changing libffi maintenance
> > and/or releases so that it isn't tied to the GCC release schedule.
>
> > I think we can do this, it just requires someone willing to do the
> > work.
>
> I would be willing to help, but I'm not sure how.

I'm primairily interested in a version libffi that can be compiled 
outside of the GCC tree without hacking the configure script and 
makefiles. Having seperate releases is not very important for me, 
although this would probably improve the appeal of libffi to other 
projects.

BTW. I'm the primairy maintainers of PyObjC, which uses libffi to 
interface Python and Objective-C. I'm very happy that libffi exists, 
thanks to all involved!


>  My background: I'm
> the author of the ctypes module for Python, an (hope I can say
> 'advanced') ffi library with good support for C compatible data types.
> This library currently uses libffi for the linux, mac os x and maybe
> other systems, and my homegrown stuff for windows.  I would be happy to
> also use libffi on Windows, but this requires some hacking to libffi to
> support some additional features I need.  Currently I have a hacked
> version in my CVS rep.
>
> >  It may also require a little bit of buy-in from the GCC SC, I'm
> > not sure.
>
> I don't understand this: what is 'GCC SC'?

The GCC steering committee.


> Thomas
>
> PS: While we're at it, a separate mailing list for libffi would also be
> great, it's impossible for me to follow the gcc devel list and locate
> the 0.3% posts about libffi ;-)

Same here, I basically don't follow libffi development at all unless I 
run into problems.

Ronald