While building Python 3.2 or Python 3.4 with Visual Studio 2013 on Windows 8.1, pythoncore.vcxproj fails to build due to illformed pre-link event command.
(FYI, I have upgraded all .vcxproj files to VS2013 locally.)

Here is the command and the error:

<pre>
1>PreLinkEvent:
1>  Description: Generate build information...
1>  cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -D_DEBUG -MDd ..\Modules\getbuildinfo.c -Fo"D:\tmp\Python-3.4.0-vs2013\PCbuild\Win32-temp-Debug\pythoncore" \getbuildinfo.o" -I..\Include -I..\PC
1>  getbuildinfo.c
1>..\Modules\getbuildinfo.c(1): fatal error C1083: Cannot open include file: 'Python.h': No such file or directory
</pre>


Notice the superfluous double quote followed by whitespace in the following argument:

<pre>
-Fo"D:\tmp\Python-3.4.0-vs2013\PCbuild\Win32-temp-Debug\pythoncore" \getbuildinfo.o"
</pre>

The problem is somewhat known as there is related comment in the make_buildinfo.c file about the custom commands arguments parsing:

<pre>
/* Hack fix for bad command line:  If the command is issued like this:
 * $(SolutionDir)make_buildinfo.exe" Debug "$(IntDir)"
 * we will get a trailing quote because IntDir ends with a backslash that then
 * escapes the final ".  To simplify the life for developers, catch that problem
 * here by cutting it off.
 * The proper command line, btw is:
 * $(SolutionDir)make_buildinfo.exe" Debug "$(IntDir)\"
 * Hooray for command line parsing on windows.
 */
</pre>

There are two solutions possible:

1) Correct the PreLinkEvent command in make_buildinfo.vcxproj according to the comment above:

<pre>
$(SolutionDir)make_buildinfo.exe" Debug "$(IntDir)\"
</pre>

2) Patch make_buildinfo.c (attached).

Then, the cl.exe command is correct:

<pre>
1>  cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -D_DEBUG -MDd ..\Modules\getbuildinfo.c -Fo"F:\V81-VS2013.win32\Librarie
s\External\Source\Python\Debug\PCbuild\Win32-temp-Debug\pythoncore\getbuildinfo.o" -I..\Include -I..\PC
1>  getbuildinfo.c
</pre>


I'm not sure why this problems leaks while building with VS2013.
I have been building Python 3.2 with VS2012 for long time w/o any issues.
Perhaps, it is related to combination of VS2013 and Windows 8.1.
Although, I'm not observing this problem while building with VS2012 on Windows 8.1,
it would be helpful if someone else who uses VS2012 or VS2013 could confirm my results.

What effect does your patch have on a VS2010 build? VS2010 is the official toolset for current Python 3.x versions so any changes we make must support that.

Also: does the same problem occur on the development branch? 

(De-selecting 3.2 as it's in security-fix mode only)

On 8 May 2014 11:53, Tim Golden <report@bugs.python.org> wrote:
>
> What effect does your patch have on a VS2010 build?

I don't know. I don't use VS2010.
However, I suspect the option 1) fix should be applied anyway as it is
suggested by the comment in make_buildinfo.c.
Why the pythoncore.vc[x]proj project files do not use "$(IntDir)\" by
default, no idea.

> Also: does the same problem occur on the development branch?

I haven't tested, I work with released Python sources now.

I noticed though, that this issue is somewhat random.
I'm building from VS2013 command prompt, and I've just successully
built the non-patched make_buildinfo.{c|vcxproj}.
This made me wonder if the problem is related to cmd.exe
configuration, extensions enabled/disabled, and such.

Attached project patch seems to build successfully on VS2010. It's possible that this failed in some way on VS2008; AFAICT it hasn't been touched since Brian first ported it two years ago.

Adding Zach Ware for a second opinion.

Your patch looks fine to me, Tim.

New changeset 469837abe5ca by Tim Golden in branch '3.4':
Issue21452 Add missing backslash to build path for make_buildinfo
http://hg.python.org/cpython/rev/469837abe5ca

New changeset a14420d8b556 by Tim Golden in branch 'default':
Issue21452 Add missing backslash to build path for make_buildinfo
http://hg.python.org/cpython/rev/a14420d8b556

Fixed. Thanks for the report

On 9 May 2014 19:21, Tim Golden <report@bugs.python.org> wrote:
>
> Fixed. Thanks for the report
>

Thank you for the fix.