> I'm using the full-blown VS.NET 2003, as given to a number of python-dev > people by Microsoft a number of years ago. This appears to come with the > SDK and a 64bit compiler.
Not sure what it makes it appear to you that way - it doesn't. VS.NET 2003 is x86 only > I'm guessing vsextcomp doesn't use the Visual > Studio 'ReleaseAMD64' configuration - would it be OK for me to check in > changes to the PCBuild projects for this configuration? Please don't. It exclusively relies on vsextcomp, and is only useful if you have that infrastructure installed. See for yourself: it uses the /USE_CL:MS_OPTERON command line switch, which isn't a Microsoft invention (but instead invented by Peter Tröger). > So is there something we can do to make distutils play better with binaries > built from PCBuild8, even though it is considered temporary? In what way better? It already supports them just fine, AFAICT. I guess you are referring to the support for building extensions on top of a source tree "installation". I doubt that is used that often (but I understand you are using it). > It seems the > best thing might be to modify the PCBuild8 build process so the output > binaries are in the ../PCBuild' directory - this way distutils and others > continue to work fine. Does that sound reasonable? I think Kristjan will have to say a word here: I think he just likes it the way it is right now. That would rather suggest that build_ext needs to be changed. > I've no objection to that - but I'd like to help keep the pain to a minimum > for people who find themselves trying to build 64bit extensions in the > meantime. I recommend that those people install the official binaries. Why do you need to build the binaries from source, if all you want is to build extensions? >> In C or in C++? In C++, wchar_t is a builtin type, just like >> short, int, >> long. So there is no further formal definition. > > This was in C++, but the problem was really WCHAR, as used by much of the > win32 API. But in C, WCHAR should not be a problem (and I would like to see explicit source code and explicit compiler error message to be proven wrong). >>> * Finally, as something from left-field which may well take >>> 12 months or >>> more to pull off - but would there be any interest to >>> moving the Windows >>> build process to a cygwin environment based on the existing autoconf >>> scripts? >> What compiler would you use there? I very much like using the VS >> debugger when developing on Windows, so that capability should not >> go away. > > You would use whatever compiler the autoconf toolset found. Recent versions > know enough about MSVC for simple projects. Many people would need to take > care that their environment pointed at the correct compiler - especially the > person building releases. > > But assuming MSVC was found and had the appropriate switches passed, there > would be no impact on the ability to use Visual Studio as a debugging > environment. I doubt that could work in practice. You will have to rewrite everything to make it pass the correct command line switches. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
