Author ned.deily
Recipients matrixise, ned.deily, r.david.murray, ronaldoussoren, yan12125, zach.ware
Date 2016-10-20.19:23:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1476991396.28.0.892508093806.issue28491@psf.upfronthosting.co.za>
In-reply-to
Content
Yes, we shouldn't be depending on pkg-config being available.  I am not at all keen on adding a dependency on a third-party library supplied by another distributor. What I would like to see is: (1) add libffi to the third-party libs built and used for the macOS installer build, which also means on all supported versions; (2) then, more generally, refactor the third-party lib builds (e.g. OpenSSL, SQLite, xz, ncurses, et al, and then libffi) out of the installer build script and provide an option to ./configure to allow the third-party libs to be built and used in a regular developer build as the absence of or lack of updates to them in macOS releases is a growing problem.  At that point we can get rid of the bundled libffi source.  At the moment, AFAIK, the presence of the bundled libffi source is not causing any problems so this isn't a critical problem, unlike the case with OpenSSL.
History
Date User Action Args
2016-10-20 19:23:16ned.deilysetrecipients: + ned.deily, ronaldoussoren, r.david.murray, zach.ware, matrixise, yan12125
2016-10-20 19:23:16ned.deilysetmessageid: <1476991396.28.0.892508093806.issue28491@psf.upfronthosting.co.za>
2016-10-20 19:23:16ned.deilylinkissue28491 messages
2016-10-20 19:23:16ned.deilycreate