On Tue, 01 Feb 2005 00:14:30 +0100, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> are there any guidelines about what to do if a Windows extension for >> Python 2.4 requires the C++ runtime (msvcp71.dll)? > >No; it should "just work fine". [...]
I fully agree with that. :) And that was actually the reason why I posted here, because in my case it did not just work fine... >> It doesn't >> sound like a good idea to me if every package places another copy of >> this dll somewhere in the Python directory. > >Why not? If your installer follows Windows logo compliance rules, it >should check whether the DLL is already present; if it is, it should >check whether the version installed is newer than the one it would >install, and if so, should skip installation. I'm creating the installer via the distutils by calling "setup.py bdist_wininst". How can I configure distutils to have it create an installer that does the above things? How should an installer check if a DLL is already present? Are DLLs registered with Windows so I can query a database? Or should the installer search for the DLL in the directories specified in the PATH variable and see if the DLL is there? And what's the preferred location for such a DLL? Should it be placed in a local directory that only belongs to the package or in a directory where other C++ extension packages might also be able to use it? But where would this be then? The Windows system directory seems to be discouraged by Microsoft: "An application should use and redistribute msvcr71.dll, and it should avoid placing a copy or using an existing copy of msvcr71.dll in the system directory. Instead, the application should keep a copy of msvcr71.dll in its application directory with the program executable." (see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_c_run.2d.time_libraries.asp) I suppose the same applies for msvcp71.dll. >> Python 2.4 does install the C runtime (msvcr71.dll) in the Windows >> system32 directory, doesn't it? > >It depends. If this is an allusers installation, it does so. For a >per-user installation, the user might not have sufficient privileges >to install into system32, so the installer won't install it there. Ah, ok. And yes, I did a "all users" installation. >> (btw, shouldn't this be installed in >> the Python directory instead?) > >No. If you install the DLL into the Python directory, Python >will not work anymore because python24.dll (installed into system32) >will not find this DLL. If you then also move python24.dll into >the Python directory, COM components that require python24.dll will >fail to run. ok, I see. >> So would it be possible that future >> Python releases would also install the C++ runtime? > >Why should it? Nothing in the Python distribution requires C++. Well, yes, I know. But I don't see Python as a standalone application. One of the great things about Python is that there are so many extension modules for every kinds of purposes. So, making available the C++ runtime would just pave the way for more of those extension modules by making it easier to distribute binary packages that are implemented in C++. >> I think it's >> better if the dll would only be installed once by Python instead of >> several times by every extension that uses C++. > >Why is that better? The DLL versioning rules, and the shared DLL >refcounting mechanisms will make sure that the installation works >just fine. I was referring to the possibility that the DLL might get installed several times at several different locations which would be a waste of disk space. If there's only one file, then I agree with the above (however, what happens if I uninstall one package and this package removes the DLL even when there are other packages installed that still require the DLL?). >> Currently, I do not package the C++ runtime and leave it up to the >> user to install the dll if it isn't already somewhere on his system. >> But this really is not a satisfying solution... > >Then you should probably include the DLL, or rewrite your extension >to not use C++. I'm afraid the latter will hardly ever be an option... ;) For one smaller package I was compiling I solved the problem by linking against the static versions of the C/C++ runtime. This will also satisfy the "It-Should-Just-Work" constraint... :) (however, there still could be situations where this is not possible (the sources might not be available, for example)). - Matthias - -- http://mail.python.org/mailman/listinfo/python-list