[python-win32] Win32Cred build errors
mhammond at skippinet.com.au
Thu Nov 27 23:31:27 CET 2008
> From the web page for the SDK I have. "This release of the SDK is intended
> replace the Windows SDK for Vista."
> But this only appears to be 0x500 rather than 0x501.
> Hence my confusion.
There is some confusion regarding these versions. In the Vista SDK, you
will find declarations along the lines of:
ObjBase.h:#define _WIN32_WINNT 0x0600
WinResrc.h:#define _WIN32_WINNT 0x0500
WinSDKVer.h:#define _WIN32_WINNT_MAXVER 0x0600
I hope you will not hold me responsible for what you find in the SDKs, but
win32cred should certainly build in any recent version.
> I get further confused when resetting the #define in win32credmodule.cpp
> has no effect. What's it there for?
> I had to debug setup.py to find the culprit and downgrade the
> windows_h_version required.
This is a side effect of when we used Visual Studio project files.
Unfortunately, one of the main contributors still uses these project files,
so I'm reluctant to kill them entirely - but that would allow us to
rationalize all management of this macro into setup.py. A Python based
build process has *far* more flexibility.
> Now win32cred builds OK, (no idea if it works but we'll ignore that for
now) and my next problem
> is either missing files or missing variables depending on which of the
> post Vista, SDK's I select.
I think I too have failed with a post-vista SDK, particularly trying to use
VS6 against it.
> I appreciate that second guessing how MS names it's SDK's and where they
> (randomly) installed is a mug's game so why attempt to duplicate and track
> it in setup.py?
Unfortunately, distutils started this "mugs game" by allowing you to build
extensions even when your environment is not set for that compiler. Indeed,
the same cmdprompt environment can build for all supported compilers without
any environment changes. So we also need to add the SDK to your
environment. Worse, many of the visual studio versions come with their own
SDK, and that SDK pointedly will *not* work for our purpose. If you ever
needed to build for multiple Python versions which span multiple compilers,
you would appreciate this is a large benefit.
> Surely trapping any MSVC errors and reporting them back would suffice?
But surely that would then have you complaining about the compiler errors -
ie, exactly how this thread started?
> Even if I achieve a build, I'm not convinced that I'll be much better off.
Agreed - making your own build doesn't leave you any better off than using
pre-built binaries. What are you trying to achieve exactly?
> I find that one of the key benefits of building a project in the MSVC
environment is that I can use
> 'goto definition' to unravel the structure of other peoples code.
I'm not sure how this is relevant. You are advocating I move back to a
visual studio build environment? Which version exactly? I currently
support 3 different MS compilers, with one of those compilers supporting
64bit builds, but Python itself doesn't "officially" support 32 and 64bit
versions installed on the same machine.
> I'm deliberately lazy when getting to grips with 'new' stuff;
So why are you putting yourself through this pain? :)
> Almost everything I have tried to do, right from finding and downloading
> sources has been less than obvious.
I'm not sure this is a reasonable critisism - surely sourceforge makes it
fairly obvious how to download either the .zip source distro, or the CVS
trunk. What do you recommend I do to improve this?
> What would help is:
> 1) certainty about exactly which MS SDK(s) are required including dates
and recent URL's.
This is too much of a moving target, especially when trying to get MSVC6 to
work with them, given the number of people who actually build from source.
I do try to keep the (large!) docstring in setup.py up to date, and for a
while even included download links in it - but I found the MS download links
went stale quicker than I needed to change SDKS!
> 2) MSVC solutions, if not for all projects, at least for the major ones.
I think you will find they already exist - but please keep in mind that the
version of VS you choose to use is not the same one that can be used to
build all supported versions. But to even more pointed - assuming I
personally do not use the VS projects, why on earth should I spend time
maintaining them on the off chance someone will come along in the future,
complain about a module not building, then complain about not having visual
studio project files available for them? What about when the next person
comes along and makes the point he is far more productive with a
make/ant/cons based build system, so therefore I should supply one of them
> I'd like this to work, I really would
Have you tried a binary?
> the alternative for me is Eclipse!
Heh - well, I'm very sorry you are having these problems, but if a few
issues building a particular complicated Python extension from source would
be enough to send you that far over the edge and into a completely different
language, it may well be worth reevaluating your requirements and exactly
what you are trying to achieve. It might also be worth considering exactly
how you would use the functionality of the win32cred module in that
environment (and indeed, if you could build such functionality from source
yourself), otherwise your comparison isn't fair.
More information about the python-win32