> From the web page for the SDK I have. "This release of the SDK is intended to > 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 three different, > 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 get > (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 the > 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 too? > 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. Good luck! Cheers, Mark _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
