I would like to update the internal copy of libffi from the 3.0.5 release to 3.0.9 (plus an ARM specific patch checked in after the 3.0.9 release). Is this ok for the trunk and the py3kbranch? I only can check linux targets and watch the buildds, so I would like to ask for tests on other targets.
The libffi subdirectories for testsuite, doc and man are currently not checked in. Should these be kept out, or should the complete libffi release be checked in?
Thanks, Matthias
Matthias Klose schrieb:
I would like to update the internal copy of libffi from the 3.0.5 release to 3.0.9 (plus an ARM specific patch checked in after the 3.0.9 release). Is this ok for the trunk and the py3kbranch? I only can check linux targets and watch the buildds, so I would like to ask for tests on other targets.
Obviously I don't do a good job maintaining the 'Python libffi fork', so I have nothing against you or other people doing my work ;-).
On the other hand: Things have changed since the first inclusion of ctypes into the Python distribution. There were no 'official' libffi releases at that time; now there are regular releases. Should the Python distribution be changed to use the system libffi by default - the '--with-system-ffi' configure option? Is a system libffi library available on OS X? On other systems? The windows fork must probably stay...
The libffi subdirectories for testsuite, doc and man are currently not checked in. Should these be kept out, or should the complete libffi release be checked in?
Depends on the answer to your first question, of course. The libffi testsuite requires dejagnus. I know there once was a Python script, written by Ronald Ossouren, which was able to execute the tests.
-- Thanks, Thomas
On Wednesday, February 24, 2010, at 08:20AM, "Thomas Heller" <theller@ctypes.org> wrote:
Matthias Klose schrieb:
I would like to update the internal copy of libffi from the 3.0.5 release to 3.0.9 (plus an ARM specific patch checked in after the 3.0.9 release). Is this ok for the trunk and the py3kbranch? I only can check linux targets and watch the buildds, so I would like to ask for tests on other targets.
Obviously I don't do a good job maintaining the 'Python libffi fork', so I have nothing against you or other people doing my work ;-).
On the other hand: Things have changed since the first inclusion of ctypes into the Python distribution. There were no 'official' libffi releases at that time; now there are regular releases. Should the Python distribution be changed to use the system libffi by default - the '--with-system-ffi' configure option? Is a system libffi library available on OS X? On other systems? The windows fork must probably stay...
OSX has a system libffi on OSX 10.5 or later. The binary installers cannot use that because libffi is not present on 10.4, and I'm also not 100% sure that libffi on 10.5 is fully binary compatible with that on 10.6.
The libffi subdirectories for testsuite, doc and man are currently not checked in. Should these be kept out, or should the complete libffi release be checked in?
Depends on the answer to your first question, of course. The libffi testsuite requires dejagnus. I know there once was a Python script, written by Ronald Ossouren, which was able to execute the tests.
I have a testrunner in pyobjc that is able to run the libffi tests without dejagnu. I'm willing to contribute that to python.
Ronald
-- Thanks, Thomas
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
On 24.02.2010 16:35, Ronald Oussoren wrote:
On Wednesday, February 24, 2010, at 08:20AM, "Thomas Heller"<theller@ctypes.org> wrote:
Matthias Klose schrieb:
I would like to update the internal copy of libffi from the 3.0.5 release to 3.0.9 (plus an ARM specific patch checked in after the 3.0.9 release). Is this ok for the trunk and the py3kbranch? I only can check linux targets and watch the buildds, so I would like to ask for tests on other targets.
Obviously I don't do a good job maintaining the 'Python libffi fork', so I have nothing against you or other people doing my work ;-).
well, I'm always buildig with --with-system-libffi for packaging, but I would like to have consistent test results on the buildds, which are not able to provide custom configure flags.
I now committed the update to the trunk; opened issue #8142 for further comments/changes.
I didn't touch the Modules/_ctypes/libffi_* directories, these maybe need updates/removals.
Proposed some changes from the libffi.diff file at http://gcc.gnu.org/ml/java-patches/2010-q1/msg00057.html
On the other hand: Things have changed since the first inclusion of ctypes into the Python distribution. There were no 'official' libffi releases at that time; now there are regular releases. Should the Python distribution be changed to use the system libffi by default - the '--with-system-ffi' configure option? Is a system libffi library available on OS X? On other systems? The windows fork must probably stay...
OSX has a system libffi on OSX 10.5 or later. The binary installers cannot use that because libffi is not present on 10.4, and I'm also not 100% sure that libffi on 10.5 is fully binary compatible with that on 10.6.
The libffi subdirectories for testsuite, doc and man are currently not checked in. Should these be kept out, or should the complete libffi release be checked in?
Depends on the answer to your first question, of course. The libffi testsuite requires dejagnus. I know there once was a Python script, written by Ronald Ossouren, which was able to execute the tests.
I have a testrunner in pyobjc that is able to run the libffi tests without dejagnu. I'm willing to contribute that to python.
I did check in the plain libffi 3.0.9 release, please could you add these changes to the trunk, and to the libffi.diff patch.
Matthias
participants (4)
-
Matthias Klose -
Matthias Klose -
Ronald Oussoren -
Thomas Heller