This is the mail archive of the
mailing list for the libffi project.
Re: Non-gcc releases
- From: Thomas Heller <theller at python dot net>
- To: tromey at redhat dot com
- Cc: libffi-discuss at sources dot redhat dot com
- Date: Thu, 25 Mar 2004 21:58:28 +0100
- Subject: Re: Non-gcc releases
- References: <email@example.com>
Tom Tromey <firstname.lastname@example.org> 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
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
> - 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
> 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.
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 ;-)