You only use /Yc on a source file that contains nothing but the #include directive for the PCH source file. Every other source file uses /Yu.
In a standard VS project, there's stdafx.h, stdafx.cpp, and various other files. The stdafx.cpp file looks like this:
Code:
#include "stdafx.h"
and is compiled with a command line like this:
cl.exe /Ycstdafx.h stdafx.cpp
yielding stdafx.pch.
All other sources are compiled with
cl.exe /Yustdafx.h source.cpp
OK, that much for the sane part. Now, the options really are quite insane. Consider that stdafx.h is empty and stdafx.cpp looks like this:
Code:
#include <iostream>
#include <string>
#include <vector>
#include <windows.h>
#include "stdafx.h"
Then the compiler will create stdafx.pch containing the information from all these headers.
While this is possible, it would be an extremely bad idea to rely on it. Let's say that source.cpp looks like this:
Code:
#include "stdafx.h"
int APIENTRY WinMain(HINSTANCE inst, HINSTANCE, LPSTR cmdline, int showcmd)
{
std::vector<std::string> args;
parse_cmdline(cmdline, args);
// ...
}
Now compile with
cl.exe /Yustdafx.h source.cpp
This will work.
Compile again with
cl.exe source.cpp
This will fail! Basically, you have different behaviour depending on whether you use PCH or not. That's totally unacceptable, which is why you should ignore this peculiarity of PCH support and simply do the sane thing: put the include directives in stdafx.h, where they belong.