Mathieu Boespflug wrote:

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?

Agree entirely, I never really understood why compiling Yhc should insist on an internet connection.

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). Given these constraints it would only be worth switching to gcc libffi if it does definitely have windows support, including working in MSVC. Thanks for all your contributions! :-) Tom