Re: Non-gcc releases

[Thomas Heller <theller at python dot net>]

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.  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'?

>
> Some issues:
>
> - libffi is in a strange state regarding copyright assignment.  We're
>   in the middle of a complicated process to get everything assigned
>   to the FSF.  I think any major new contributors have to be willing
>   to sign papers at some point in the future (unfortunately I think
>   the FSF won't accept paperwork until the existing code has been
>   assigned, complicating everything)
>
>   We'd probably need FSF paperwork to get anybody new write access to
>   the gcc repository at all.
>
>   The license won't change as a result of this.  So no worries there.
>
> - The gcc tree has rules about when it is or is not acceptable to
>   make certain sorts of changes.  This could interfere with whatever
>   release schedule we come up with for libffi.
>
>   This is easy enough to work around by making branches for libffi
>   work when that work conflicts with gcc.  We'll want to make release
>   branches anyway, since we'll want to give libffi its own version
>   numbers.

Sounds great.

> - Perhaps we should at least get approval from the SC to use the tree
>   for this sort of thing?
>
> Etienne and I also discussed moving libffi out of the gcc tree and
> into its own repository somewhere.  I'd prefer not to do this.  My
> impression was that Etienne could find someone to do releases and that
> sort of thing, but that doing actual libffi maintenance was too much
> work.  One nice advantage of keeping the code in the gcc tree is that
> there are many platform and ABI experts around, so we can run the
> various bits of assembly code past them for approval.  I think getting
> this sort of review out-of-tree would be much more difficult.

I would find it cool if libffi could have its own build procedure, test
procedure, and documentation without relying too much on the rest of the
gcc tree.

> Anything else?
>
> If you know someone who is interested in this discussion, by all means
> have them subscribe here and take part.  Ideally we'd get all the
> libffi users together to make decisions.  Until now we've pretty much
> made decisions unilaterally for libgcj's benefit, but we can and
> should change this to include anyone interested in the project.

I have posted a message both to the ctypes users list, and to the PyObjc
list which also uses libffi.

> Tom

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