On Fri, May 27, 2016 at 2:42 AM, Chris Barker <chris.bar...@noaa.gov> wrote: > On Wed, May 25, 2016 at 1:40 PM, Chris Angelico <ros...@gmail.com> wrote: >> >> But why should CPython >> package a runtime that it doesn't use? > > > Because it IS part of the "standard runtime environment" that cPython is > providing. The cPython Windows builds are built with a particular compiler > that expects a particular runtime. C++ is part of that runtime, even if the > cPython code itself doesn't use that part. I'm sure there are features in > the C runtime DLL that cPython doesn't happen to use, either. The fact that > it's a separate dll is kind of an implementation detail.
I'm not sure that it is an implementation detail; it's indicative that the compiler/runtime designers intended for the C runtime to be able to be distributed without the C++ runtime. You wouldn't expect to have to ship a Fortran runtime and a Cobol runtime, even if MSVC happened to package up compilers for all of the above, would you? >> Which is more common - someone >> uses two C++ modules, or someone uses none of them? > > > Irrelevant -- which is the bigger problem for users? a lot of folks getting > an extra dll as part of a large install that they aren't using, or folks > getting cryptic error messages and/or every package builder of C++ packages > having to identify and solve the problem? I agree with you that end users getting cryptic error messages is a problem. But the choice of solutions is: 1) CPython ships the C++ runtime that it doesn't use, in case someone pip-installs something that needs it 2) Package authors who choose to use C++ must ship the C++ runtime. Even apart from the DLL Hell that Steve mentioned, the second option appears more sane. Package authors get the freedom to choose any runtime dependencies they want, and then they package them or make it possible to obtain them. > BUT -- Steve Dower seems to have identified that the wonders of dll hell > never cease, and this isn't possible anyway. Oh well. > I'm not entirely grasping what's happening here. There are multiple versions of msvcp140.dll floating around out there; what happens if one app requires one of them and another requires another? Can you simply say "take the newer one"? Is there a way to instantly recognize that there's a newer one available, and ignore the older one? Versioning is a *pain*. ChrisA _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
