There is no single such document I'm aware of. Each version of Python has exactly one official MSVC version, details of which can be found in Python's PCBuild\readme.txt file. pywin32 uses distutils, and that too only supports a single supported version - although other versions are supported in one way or another (googling for MSSdk and DISTUTILS_USE_SDK should work). VS2008 is supported by both Python and pywin32's svn/cvs trunk, so maybe that is an option for you. The lack of official support and documentation is part of the burden I mentioned <wink>
Cheers, Mark From: Vernon Cole [mailto:[EMAIL PROTECTED] Sent: Tuesday, 29 January 2008 4:21 PM To: Mark Hammond Cc: Tim Roberts; Python-Win32 List Subject: Re: [python-win32] Embedding/bundling Python, best practices? Mark: Where can one find a cookbook for HOW to build python and/or pywin32 from source? I guessed that one should use VS 2003 (which I have) but I have no clue how to make it actually compile. Someone mentioned a patch to compile using a later (2005?) version of Visual Studio. I really want to try with VS 2008 express, so that I can work on my home machine, rather than the one at work where we have the licen$ed version, but the first step is to make it work with the supported environment. Where do I look for documentation? -- Vernon Cole On Mon, Jan 28, 2008 at 5:28 PM, Mark Hammond <[EMAIL PROTECTED]> wrote: TimR wrote: > You need to set the Python path variable before calling the > interpreter. You can do that by setting the PYTHONPATH environment > variable, but I believe you can also do that by setting variables when > you initialize the interpreter. Actually, if the 'lib' directory can be found relative to pythonxx.dll, it should not be necessary to set PYTHONPATH at all. Even then, if it *was* necessary to set such a variable, it may be better to set PYTHONHOME instead - that should adjust PYTHONPATH (again, the lib can be located relative to that dir), along with ensuring sys.prefix etc are all correct, thereby allowing things like distutils to do the right thing. > Py2exe might prove useful for you, if only because it scans through a > Python script and determines exactly which auxiliary DLLs and modules > the script needs in order to operate in a standalone environment. > > > Also, our application is built with VS 2005, should Python also be > > built with the same VS version for compatibility? > > > > Yes, this is required. The Python run-time DLL links to the Visual C++ > run-time library. My python24.dll, for example, links to msvcr71.dll, > which is the run-time from VS 2003. On the other hand, it would work fine if you built Python and all modules with the same compiler. You can not *mix* compilers, but using a non-default one should work fine so long as you control every binary you load. That is a burden though. Cheers, Mark _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
_______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32