Author zach.ware
Recipients Arfrever, berker.peksag, chris.jerdonek, doko, fabiovmp, gustavotemple, koobs, lemburg, meador.inge, r.david.murray, steve.dower, tim.golden, xdegaye, yan12125, zach.ware
Date 2016-07-27.22:28:06
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1469658487.02.0.0371790673729.issue23085@psf.upfronthosting.co.za>
In-reply-to
Content
OSX and Windows are both exempt from this discussion.  Each has its own private copy of an ancient version of libffi: Modules/_ctypes/libffi_osx/ and Modules/_ctypes/libffy_msvc/.

I would be in favor of switching to --with-system-ffi by default for 3.6 and deprecating building with the bundled full copy of libffi (Modules/_ctypes/libffi/), to be removed in 3.7.  OSX would also default to --with-system-ffi, but would still fall back to its private copy when a system copy isn't available.

It seems like most Linux and BSD distributions would be better off with system-ffi.  I'm not sure how cross-builds would have to deal with things in 3.7, but they already have to deal with dependencies like openssl, bz2, and lzma; adding libffi to that mix shouldn't be that big of a deal.

Adding Ned to confirm that building OSX installers wouldn't be affected as long as we don't touch Modules/_ctypes/libffi_osx/ and there's not a system copy of libffi available.
History
Date User Action Args
2016-07-27 22:28:07zach.waresetrecipients: + zach.ware, lemburg, doko, tim.golden, Arfrever, r.david.murray, meador.inge, chris.jerdonek, xdegaye, berker.peksag, koobs, steve.dower, gustavotemple, fabiovmp, yan12125
2016-07-27 22:28:07zach.waresetmessageid: <1469658487.02.0.0371790673729.issue23085@psf.upfronthosting.co.za>
2016-07-27 22:28:07zach.warelinkissue23085 messages
2016-07-27 22:28:06zach.warecreate