On Wed, May 20, 2015 at 12:46 AM, Paul Moore <p.f.mo...@gmail.com> wrote:
> On 19 May 2015 at 16:22, Chris Barker <chris.bar...@noaa.gov> wrote: > > The other issue is social: this would really only be a benefit if a wide > > variety of packages shared the same libs -- but each of those packages is > > maintained by different individuals and communities. So it's had to know > if > > it would get used. I could put up a libpng wheel, for instance, and who > > knows if the Pillow folks would have any interest in using it? or the > > matplotlib folks, or, ... And this would be particularly difficult when > the > > solution was hacked together... > > Honestly, I still haven't seen a solid explanation of why (at least on > Windows) static linking isn't a viable option. Because some libraries simply don't work as static libraries, or are too big (MKL comes to mind). Also, we have been historically using static libs for our eggs at Enthought on windows, and it has been a nightmare to support. It just does not scale when you have 100s of packages. But really, once wheels support arbitrary file locations, this becomes fairly easy at the packaging level: the remaining issue is one of ABI / standards, but that's mostly a non technical issue. Gholke has 100s of packages using wheels, and we ourselves at Enthought have close to 500 packages for windows, all packaged as eggs, maybe 30-40 % of which are not python but libs, C/C++ programs, etc... It is more about agreeing about a common way of doing things than a real technical limitation. David If someone were to > create and publish a Python compatible static ".lib" file for the > various hard-to-build dependencies, extensions could specify that you > link with it in setup.py, and all the person building the wheel has to > do is download the needed libraries for the build. > > If there's a technical reason why dynamic linking at runtime is better > than static linking (sufficiently better that it justifies all the > effort needed to resolve the issues involved), then I've yet to see a > good explanation of it. The only things I've seen are disk space, or > maintenance (where this usually means "it's easier to release a new > DLL with a security fix than get all the various statically linked > packages updated - that's a valid point, but given how hard it is to > get a working dynamic linking solution in this environment, I have to > wonder whether that argument still holds). > > All of this applies to Windows only, of course - dynamic linking and > system management of shared libraries is very much a per-platform > issue, and I don't pretend to know the trade-offs on OSX or Linux. > > Paul > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
