> > Instead of importing libffi from the python sources, I propose using
> > another, more complete version. libffi does not seem to be currently
> > maintained due to copyright issues but there seems to be a version of
> > it distributed by gcc-4.2 which is much more recent and complete. I
> > get the impression that version works on all platforms gcc has been
> > ported to (could be wrong though).
>
> At the time we made the choice we considered both the python ctypes
> version and the gcc version. In the end we rejected the gcc version
> because it didn't have any support for the windows platform, whereas the
> python version had been modified by the ctypes people so that it did.
>
> Now it's entirely possible that this has now changed and the gcc version
> supports windows, including use with MSVC. Since Neil insists that Yhc
> should compile with MSVC (pfft, I never saw why, mingw always worked
> nicely for me - though that's a different issue).
The GCC version does have support for windows as far as I can tell
(see depends/libffi/default/src/x86/win32.S). But of course it won't
build unless you have mingw etc. For people who are quite happy to use
mingw under windows to compiler Yhc, things should work with little
extra modifications if any. For people that insist on MSVC I have
included depends/libffi/msvc, which comes from the python ctypes
version, actually. So this should keep everyone happy. :-)
For building BCKernel and libffi using MSVC it will require to add
support for that in src/runtime/BCKernel/CMakeLists.txt, of course.
Any takers?
We could of course replace the libffi autoconf stuff with CMake files
and gain support for building the gcc libffi with MSVC, but I don't
think it's worth it. It would be a lot of work and not much point in
that.
> Given these constraints it would only be worth switching to gcc libffi
> if it does definitely have windows support, including working in MSVC.
That is a simple case of adding the support into the Yhc CMake files.
On the flipside we get a more modern libffi with more architectures
supported. I remember giving up porting Yhc to my armel based N800
device because the ctypes libffi doesn't have armel support, only arm
(and also because the scons build system was making life terribly
difficult..). I haven't reiterated the attempt with the gcc libffi but
google tells me the libffi in gcc-4.2 does support that architecture.
Note that this libffi update patch only supports CMake. I don't
understand scons. Anyone interested in making the appropriate changes
to scons to work with this patch?
Mathieu
