On 23/11/2011 07:35, Ian Zimmerman wrote:
David> I'm glad it works for you. When I tested it with Debian and David> Ubuntu I had to install the development packages but otherwise it David> went smoothly. I'm considering adding libffi to the poly source David> since it's licensed under the BSD licence. Ian> I understand the appeal of this solution, but at least on Debian it Ian> is seriously frowned upon. The maintainer of the Debian package Ian> would probably have to undo it and use the pkg-config interface Ian> anyway to get the package accepted. David> What is the problem? Is it the licensing or the inclusion of a David> library that is already separately available as a package? I was David> really considering it specifically for use on Windows where David> mingw/msys doesn't include pkg-config (though I did manage to David> find a version on the gtk download site, so it's not really an David> issue any more). As I understand it, the objection to embedding external library sources is twofold: both "philosophical" and practical. The philosophical part is that Debian tries to do The Right Thing (TM) even if it is hard, and I think that we can all agree that The Right Thing in this context is to link to an existing shared library as opposed to embedding the source. The practical part has mostly to do with security fixes. If a vulnerability is discovered in libffi, there is no way to scan the sources of all the ~30k packages and hunt for those that might contain a copy of libffi to fix them.
Fine. By "adding libffi to the poly source" I wasn't implying that when poly was compiled it would only use that version of libffi. I had in mind the idea that a user/packager would be able to override this and use the version installed on the system. I can envisage situations where the version of libffi on the system might be tailored for the system and the user might want to force poly to use that in preference.
If libffi were like the C/C++ libraries and available consistently on all platforms there would be no need to consider including it in the source. However, it's becoming clear that on a significant range of platforms using it would require users to install libffi from source and/or to make non-trivial tweaks to their system. I think it's important to try and ensure that when users download the tar-ball from Sourceforge they should be able to compile and install Poly/ML with the least amount of trouble. It looks like that can best be achieved by including libffi within the source and building with that by default. Packagers and users with special requirements can override that if they need to. That approach would seem to overcome any objections.
David _______________________________________________ polyml mailing list [email protected] http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
