I tried to build PC/VS9.0/pcbuild.sln using Visual Studio 2008, but it failed:

1>------ Build started: Project: make_buildinfo, Configuration: Release Win32 ------
2>------ Build started: Project: kill_python, Configuration: Debug x64 ------
2>Compiling...
1>Compiling...
2>kill_python.c
1>make_buildinfo.c
2>c1 : fatal error C1083: Cannot open source file: '.\kill_python.c': No such file or directory
1>c1 : fatal error C1083: Cannot open source file: '.\make_buildinfo.c': No such file or directory
2>Build log was saved at "file://Z:\default\PC\VS9.0\x64-temp-Debug\kill_python\BuildLog.htm"
2>kill_python - 1 error(s), 0 warning(s)
1>Build log was saved at "file://Z:\default\PC\VS9.0\Win32-temp-Release\make_buildinfo\BuildLog.htm"
1>make_buildinfo - 1 error(s), 0 warning(s)
3>------ Build started: Project: make_versioninfo, Configuration: Debug Win32 ------
4>------ Build started: Project: w9xpopen, Configuration: Debug x64 ------
3>Compiling...
4>Compiling...
3>make_versioninfo.c
4>w9xpopen.c
3>c1 : fatal error C1083: Cannot open source file: '..\PC\make_versioninfo.c': No such file or directory
4>c1 : fatal error C1083: Cannot open source file: '..\PC\w9xpopen.c': No such file or directory
3>Build log was saved at "file://Z:\default\PC\VS9.0\Win32-temp-Debug\make_versioninfo\BuildLog.htm"
3>make_versioninfo - 1 error(s), 0 warning(s)
4>Build log was saved at "file://Z:\default\PC\VS9.0\x64-temp-Debug\w9xpopen\BuildLog.htm"
4>w9xpopen - 1 error(s), 0 warning(s)
5>------ Build started: Project: pythoncore, Configuration: Debug x64 ------
5>Compiling...
5>traceback.c
5>c1 : fatal error C1083: Cannot open source file: '..\Python\traceback.c': No such file or directory
5>thread.c
5>c1 : fatal error C1083: Cannot open source file: '..\Python\thread.c': No such file or directory
5>sysmodule.c
[etc.]

Building with VS 2008 isn't officially supported anymore. If users want to continue to use VS 2008, they need to contribute patches. Preferably, the project files would be generated from the VS2010 project files, but for the moment, manually editing to make them work again might be fine as well.

Unassigning Brian for now - Brian, if you want to work on this, feel free to assign yourself again.

> Building with VS 2008 isn't officially supported anymore. If users
> want to continue to use VS 2008, they need to contribute patches.

Well, VS 2010 is probably a multi-GB download and install. Besides,
having to juggle between two different VS versions will quickly become
confusing.

Speaking as a non-native Windows developer, there are enough hoops I
must jump through to do occasional testing under a Windows VM. So I
might simply stop caring.

> Well, VS 2010 is probably a multi-GB download and install. Besides,
> having to juggle between two different VS versions will quickly become
> confusing.

Sure. However, it is not feasible to keep the build systems for many
VS versions up-to-date, just because contributors are shy of installing
the current version. Tracking two build systems (autoconf and VS) is
already difficult enough.

> Speaking as a non-native Windows developer, there are enough hoops I
> must jump through to do occasional testing under a Windows VM. So I
> might simply stop caring.

This is free software. If you don't want to care, you don't have to.
It's the same as switching from Subversion to Mercurial: we probably
lost some contributors who never bothered to learn Mercurial. That
didn't stop us from switching. I expect that most occasional contributors
will find it easier to use VS 2010 than VS 2008.

> This is free software. If you don't want to care, you don't have to.

Of course. I'm just pointing this out in relation with the fact that we
don't have many Windows-based developers :-)

> I expect that most occasional contributors
> will find it easier to use VS 2010 than VS 2008.

Are there any features which make VS 2010 easier to use for us?

> Are there any features which make VS 2010 easier to use for us?

I don't do much with the IDE besides the basics of writing the code and building it, so I can't really say if it makes anything easier on us. I think the change is just going to be doing the same thing on a newer version.

The change is more driven from keeping up with what everyone else is using. I did a VS2010 port at my old job over a year ago because we needed it, and CCP games (Kristjan) moved to VS2010 even before that.

I will look through and see what it may provide that we could take advantage of, but I don't remember seeing much that we could use. C# gets all of the goodies, then C++ is in second place, and all we in C world really get is a new CRT version. However, if we didn't change to 2010 now, due to our release schedule we'd be stuck with VS2008 until at least 2014, which would be at least two VS versions behind by then.

> Are there any features which make VS 2010 easier to use for us?

Not for us, but for our users. Users request to build Python with VS 2010,
because that's all they have. It's already a major pain for Python Windows
developers to discover that they can't build Python 2.7 extensions with their
VS installation. So we absolutely have to use the latest VS release for each
Python release - we will be using that for at least two years, at which
point VS 2008 may not be available anymore from MS.

VS 2008 will end its mainstream support on April 9, 2013; the Extended Support
will be available until April 10, 2018. I'm not entirely sure about  
the policy,
but I think commercial availability ends with the mainstream support (i.e. in
a year from now). I'm also not sure whether this means that they will take
VS Express 2008 off the net (which also expires its mainstream support  
in 2013).

FWIW, VS 2010 Pro has mainstream support until July 14, 2015, and extended
support until September 8, 2020 (at this point; they may extend it depending
on when the successor version becomes available).

I also would appreciate if the VS 2008 build still worked. Currently I
can't build the 64-bit version with either VS 2008 or VS 2010:


TRACKER : error TRK0002: Failed to execute command: ""C:\Program Files (x86)\Microsoft Visual Studio 10 
.0\VC\BIN\amd64\CL.exe" @C:\Users\stefan\AppData\Local\Temp\f9f116658f704924b06aa34172aa7fb2.rsp". The  
handle is invalid. [C:\Users\stefan\pydev\cpython\PCbuild\make_buildinfo.vcxproj]

Does that failure happen to you every time? I occasionally see those RSP files causing some failures, but those are something created by Visual Studio (2008 as well) and they sometimes get held open or cause problems being deleted. I've always had success just rebuilding again and it works.

I just built the 64-bit release version right now with no issue.

This happens every time. It wasn't an issue with VS 2008. I'm building
on the command line:

"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64\vcvars64.bat"

msbuild /p:useenv=true pcbuild.sln /p:Configuration=Debug /p:Platf
orm=x64


Also, I can't locate vcvarsall.bat. Perhaps I failed to click some
hidden 64-bit option during install.


"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\amd64\
CL.exe" is present though and it works.

> I also would appreciate if the VS 2008 build still worked.

Then provide patches.

This is bizarre. The same command line that fails during build works
when I paste it manually:

[During build]
  C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\amd64\CL.exe /c /I..\Include /I..\PC /Zi / 
  nologo /W3 /WX- /Od /Ob1 /Oi /Oy- /D _CONSOLE /D NDEBUG /D _WIN32 /GF /Gm- /MT /GS /Gy /fp:precise /Z 
  c:wchar_t /Zc:forScope /Fo"C:\Users\stefan\pydev\cpython\PCbuild\Win32-temp-Release\make_buildinfo\\" 
   /Fd"C:\Users\stefan\pydev\cpython\PCbuild\Win32-temp-Release\make_buildinfo\vc100.pdb" /Gd /TC /anal 
  yze- /errorReport:queue make_buildinfo.c                                                              
TRACKER : error TRK0002: Failed to execute command: ""C:\Program Files (x86)\Microsoft Visual Studio 10 
.0\VC\BIN\amd64\CL.exe" @C:\Users\stefan\AppData\Local\Temp\086a4b92ff8e47e594a60a863ffd70e4.rsp". The  
handle is invalid. [C:\Users\stefan\pydev\cpython\PCbuild\make_buildinfo.vcxproj]


[Manually: no error]

C:\Users\stefan\pydev\cpython\PCbuild>"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\amd64\
CL.exe" /c /I..\Include /I..\PC /Zi /nologo /W3 /WX- /Od /Ob1 /Oi /Oy- /D_CONSOLE /DNDEBUG /D_WIN32 /GF 
/Gm- /MT /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Fo"C:\Users\stefan\pydev\cpython\PCbuild\Win32-te
mp-Release\make_buildinfo\\" /Fd"C:\Users\stefan\pydev\cpython\PCbuild\Win32-temp-Release\make_buildinfo
\vc100.pdb" /Gd /TC /analyze- /errorReport:queue make_buildinfo.c                                       
make_buildinfo.c

> This is bizarre. The same command line that fails during build works
> when I paste it manually:

I'm having problems with F-Secure, VS 2010, and make_buildinfo. F-Secure
thinks that make_buildinfo.exe has a virus in it, and quarantines it.
I had to disable the life scanner to make it work. You might want to
try disabling the virus scanner as well.

Martin v. L??wis <report@bugs.python.org> wrote:
> I'm having problems with F-Secure, VS 2010, and make_buildinfo. F-Secure
> thinks that make_buildinfo.exe has a virus in it, and quarantines it.

I don't have a virus scanner, since I only use the VM for testing.
Apparently many people had this problem. Here's a thread with
Microsoft claiming that the problem is due to a case sensitive file
system:

http://connect.microsoft.com/VisualStudio/feedback/details/505682/x64-c-c-projects-cannot-compile

As several other people in that thread, I'm pretty certain that I
didn't install SUA. Also, I can create lower case files and open
them as upper case.

Here's a patch. I can build win32 and "Release|x64". However, the
executables immediately exit; this might be related to #14822.

Regarding the VS 2010 build failure, using the cross tools builds
python_d.exe:

"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64\vcvarsx86_amd64.bat"
msbuild /p:useenv=true pcbuild.sln /p:Configuration=Debug /p:Platform=x64

Again, the executables immediately exit (#14822 ?).

The patch doesn't apply here, line endings perhaps?

Probably line endings. It applies with cygwin's patch:

C:\Users\stefan\pydev\cpython>patch -p1 < vs-9.0.diff                                                           
patching file PC/VS9.0/_bz2.vcproj                                                                              
patching file PC/VS9.0/_ctypes.vcproj
[...]

I'm uploading a dos version.

> I'm uploading a dos version.

Still doesn't work. It may be because I'm doing all this in a Linux checkout without the hgeol extension enabled, though.

Hm, vs-9.0.diff applies here on Linux, too. A final try... :)

> Hm, vs-9.0.diff applies here on Linux, too. A final try... :)

Works, thank you :-)

Both debug x64 and release x64 executables seem to work here, with latest tip.

[VS 2008]

Most recent tip is ok here, too: all executables run again.


There's still a link failure in "Debug|x64" mode, but that appears
harmless:


 lib /def:python33stub.def /out:C:\Users\stefan\pydev\cpython\PC\VS9.0\x64-pgo\python33stub.lib /MACHINE:x64    
Microsoft (R) Library Manager Version 9.00.21022.08                                                             
Copyright (C) Microsoft Corporation.  All rights reserved.                                                      
   Creating library C:\Users\stefan\pydev\cpython\PC\VS9.0\x64-pgo\python33stub.lib and object C:\Users\stefan\p
ydev\cpython\PC\VS9.0\x64-pgo\python33stub.exp                                                                  
LINK : fatal error LNK1104: cannot open file 'C:\Users\stefan\pydev\cpython\PC\VS9.0\x64-pgo\python33stub.lib'  
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\x86_amd64\lib.EXE"' : ret
urn code '0x450'                                                                                                
Stop.                                                                                                           
Project : error PRJ0019: A tool returned an error code from "Performing Makefile project actions"

> Preferably, the project files would be generated from the VS2010 project files, but for the moment, manually editing to make them work again might be fine as well.


Martin, Brian: Can I go ahead with vs-9.0.diff or would it interfere
with your work?

I don't have time at the moment to test it, but the patch looks like it's probably ok.

Zitat von Stefan Krah <report@bugs.python.org>:

> Stefan Krah <stefan-usenet@bytereef.org> added the comment:
>
>> Preferably, the project files would be generated from the VS2010  
>> project files, but for the moment, manually editing to make them  
>> work again might be fine as well.
>
>
> Martin, Brian: Can I go ahead with vs-9.0.diff or would it interfere
> with your work?

It's fine with me.

New changeset f6a207d86154 by Stefan Krah in branch 'default':
Issue 14813: Fix Visual Studio 2008 build after the move into the PC/VS9.0
http://hg.python.org/cpython/rev/f6a207d86154

Is there anything left to do or can I close this bug?

I don't have my Windows VM anymore, so unfortunately I won't be able to tell you whether there is still a build problem :)

Building the external packages isn't fixed yet, but I don't know if it's
worth the trouble.