RetroSearch Browse

Thu Jan 26 16:33:08 CET 2006 · https://mail.python.org/pipermail/python-dev/2006-January/060112.html

Ronald Oussoren <ronaldoussoren at mac.com> writes:

> On 26-jan-2006, at 13:29, Thomas Heller wrote:
>
>> Thomas Wouters <thomas at xs4all.net> writes:
>>
>>> On Thu, Jan 26, 2006 at 09:54:51AM +0100, Thomas Heller wrote:
>>>
>>>> The current state is that ctypes uses GPL'd tools to build libffi,
>>>> and those can't be committed into Python SVN.
>>>
>>>> http://mail.python.org/pipermail/python-dev/2006-January/059937.html
>
> It shouldn't be too hard to use Python's main configure script to
> calculate the information necessary to build libffi. A lot of it is
> already calculated anyway (sizeof various type, endianness), some can
> be hardcoded (FFI_NO_RAW_API).
>
> In PyObjC I just compile the files I need from my setup.py. But I have
> an easy task, I just need to support two CPU architectures on one OS.

Thanks for the encouragement - Martin suggested a similar approach.

>From my understanding (which goes not very far) the configuration does
two things: determine the set of source files that needs to go in
depending on the cpu architecture, and to determine some information and
make them available in #defines.  I have to check if this is possible
without patching the libffi sources themselves. I guess I could look
into the PyObjC setuop script.

Personally I only have access to machines running windows, linux (x86
and x86_64), and OS X (plus possibly a Mac running ubuntu), so I could
only do it for those.  Maybe support for other architectures can be
added by volunteers?

Besides:  James Y Knight seems to be correct that all the scripts needed
to build libffi seems to have this special exception from the GPL.

Thomas

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-January/060112.html below:

python-dev Summary for 2006-01-01 through 2006-01-15