[Python-Dev] libffi embedded in CPython

[Benjamin Peterson]

On Thu, Dec 18, 2014, at 15:36, Jim J. Jewett wrote:
> 
> 
> On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote:
> > ... http://bugs.python.org/issue23085 ...
> > is there any reason any more for libffi being included in CPython?
> 
> [And why a fork, instead of just treating it as an external dependency]
> 
> Benjamin Peterson responded:
> 
> > It has some sort of Windows related patches. No one seems to know
> > whether they're still needed for newer libffi. Unfortunately, ctypes
> > doesn't currently have a maintainer.
> 
> Are any of the following false?
> 
> (1)  Ideally, we would treat it as an external dependency.
> 
> (2)  At one point, it was intentionally forked to get in needed
> patches, including at least some for 64 bit windows with MSVC.
> 
> (3)  Upstream libffi maintenance has picked back up.
> 
> (4)  Alas, that means the switch merge would not be trivial.
> 
> (5)  In theory, we could now switch to the external version.
> [In particular, does libffi have a release policy such that we
> could assume the newest released version is "safe", so long as
> our integration doesn't break?]
> 
> (6)  By its very nature, libffi changes are risky and undertested.
> At the moment, that is also true of its primary user, ctypes.
> 
> (7)  So a switch is OK in theory, but someone has to do the
> non-trivial testing and merging, and agree to support both libffi
> and and ctypes in the future.  Otherwise, stable wins.
> 
> (8)  The need for future support makes this a bad candidate for
> "patches wanted"/"bug bounty"/GSoC.

Sounds about right.