[ctypes-users] Re: Let's release 0.6.4

[Thomas H. <th...@py...>]

[Thomas]
>> I assume you mean the code in types.c - I already suggested to the
>> libffi people to switch to a scheme like that in Python's
>> structmodule.c, where the C compiler figures out the alignment, instead
>> of the hardcoded preprocessor commands.

[Bob]
> Yeah, that shouldn't be hard to do.  Maybe we should just make those
> modifications ourselves.

Replacing libffi's types.c is trivial.

>> Which makes me wonder if it wouldn't be better to have patched libffi
>> sources in ctypes CVS.  I have severly hacked it for MSVC.
>

> We could just make this hacked version build and work cross-platform,
> though keeping it in sync with the official libffi tree is going to be
> pretty hard (though I'm not entirely sure we'll have a reason to).

Depends on how often they add new features, or other architectures.

>> Since there are currently no official libffi releases, wouldn't it even
>> be the best to compile it into the _ctypes extension, instead of
>> building a shared library from it?  The only thing I do not know is how
>> to combine the configure stuff needed with distutils.
>
> I generally don't use shared libraries unless there's a really good
> reason to do so anyway.  They are especially a pain in the ass if you
> want to redistribute something as a standalone application.  It just
> doesn't make sense to use shared libraries unless you have a lot of
> executables that are going to be using it simultaneously (to save on
> RAM).

Ok, so we can try to compile it into _ctypes.  The question remains:
What about the configure step?  Should we manually maintain the files it
creates (or whatever it does ;-) in CVS, or do the Python header files
contain enough info to compile the libffi sources?

Thomas