[Yhc] Replacing libffi with version distributed in gcc-4.2

Mathieu Boespflug mboes at tweag.net
Tue Nov 6 08:57:57 EST 2007


Hi all,

Here is another proposed update for the YHC repository. Currently as
part of the build process either a snapshot is downloaded or a
subversion checkout is made on the libffi sources as found in the
Python subversion repository. When delving into the scons build system
for Yhc the first thing I did was import a version of libffi into the
Yhc repository. The build system shouldn't pull something of the
Internet every time a target needs to be built and make that target
fail when an Internet connection is not available. Also, isn't it best
to compile against a version that the Yhc developers know to work,
reimporting libffi from upstreams as the developers see fit and as the
developers get time to test that it works fine?

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).

However, the version in gcc-4.2 uses autotools to build, so I've also
imported two other versions of libffi into the tree, libffi-arm_wince
and libffi-msvc for building Yhc on windows platforms. The gcc-4.2
version is in depends/libffi/default whilst the other two are in
depends/libffi/{arm_wince,msvc}.

The CMake based build system has support for building libffi-gcc-4.2,
but not the wince and msvc versions, since I don't have any windows
machines at hand to test this. Could some windows guru take care of
getting libffi to work with CMake on Windows platforms?

The patch for importing this new libffi version can be pulled from

http://code.haskell.org/~mboes/yhc.cmake

Regards,

Mathieu


More information about the Yhc mailing list