On 18/04/2013 00:46, Phil Clayton wrote:
On 12/04/2013 12:54, David Matthews wrote:
Based on this, I think there would be a case for setting the default for Poly/ML to be --disable-shared so that producing the dynamic version requires an explicit option.
I've now committed this change. The default is now not to build the shared library but that can be overridden with --enable-shared. Like any change in SVN it's always provisional so it can be reverted if necessary. I'd like feedback either for or against.
The main downside that I can see with this approach is that the SO files are not built or installed. Therefore, with a standard installation, it would not be possible for a Poly/ML-based application to choose whether to link dynamically or statically to the Poly/ML libs.
This is really quite difficult and I can see arguments for and against. It's all about trying to make it easy for users to get up and running with Poly/ML and to be able to do what they would like to do without much hassle. The difficulty is in trying to understand how it might be used in various contexts.
As far as I can see the only real losers as a result of the change to static library by default would be those who build the system from source and then want to compile and link several executables produced with PolyML.export.
I expect that anyone packaging Poly/ML for a distro where the binary and libraries are installed to, say /usr/bin and /usr/lib, would know enough to be able to specify --enable-shared. They would probably be overriding --prefix anyway. That takes care of users who install through their package manager.
Anyone installing Poly/ML from source and only building "poly" won't really be any worse off because although the "poly" binary will be bigger there won't be the extra space for the shared library. It will also avoid the need for library paths if it is installed to a non-standard place.
David