[Python-Dev] Adventures with x64, VS7 and VS8 on Windows

[Mark Hammond]

Hi Martin,

> > 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

Yes - I was confused by finding an x64 configuration option, and this
looking very similar to VC8.  My apologies for the confusion.

> > 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).

Yes, that is correct.  I agree it will be rarely used by Python user's, but
believe it is a common scenario for people who maintain extensions or
libraries, particularly those who want debugging builds.

> > 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.

So this means PCBuild8 does indeed get formalized into distutils?  I'm happy
to live with it if it lets me work, but it seems contrary to our emails
yesterday.  It would also mean the PCBuild8 environment will not work with
external build processes that assume the standard layout, but that really
isn't something I'm willing to run the pydev gauntlet for at the current
time.

> > 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?

Let's assume that people have a valid reason to build from source - it
really is quite common in the open source world.  The meta-question then
becomes "is it reasonable to expect people be able to build extensions from
a tree built with VC8, in the same way they can with VS7?".  I think you are
suggesting we do want to support this, but I want to be clear.

>
> >> 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).

Please see my other mail to Kristjan - at this stage I can only reproduce it
in C++ on VC8.  C++ on VC7 and C on VC8 both work fine.  Please let me know
if thde code snippet I pasted or the compiler error aren't suitable.  I've
stopped further investigation since there seems support for a change that
makes the problem go away.

> >>> * 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.

'have to rewrite everything' sounds a little pessimistic, but that's fine
with me - consider this idea dropped.

Cheers,

Mark