I have a custom tool that I want to run as part of the compile process, between the preprocessing and compiling. For GCC, I do:
gcc [options] -E source.c | mytool | gcc [options] -c source.o -xc -
However, I haven't figured out how to do something similar for MSVC. Currently I have
cl.exe [options] /EP source.c | mytool.exe > temp.c
cl.exe [options] /c temp.c
The problem here is that for every source file (thousands), I have an additional disk write/read cycle. Additionally, when MSVC outputs the .i files, they tend to get really large. Over 10MB large. So the 10MB disk I/O per file piles up really quickly.
So, my questions:
1) Is it possible to get cl.exe to read treat stdin as an input file?
2) If not, is it possible to create a memory mapped file it can read from?
3) Is there a better way to do this?
And no, "get an SSD" and "don't use MSVC" are not valid answers, sorry.
Related (but not solving the speed issue)
For future reference: I've found no way to trick cl.exe to read from memory instead of disk.
However, I managed to speed up the process to acceptable speed by using the GNU CPP for the first stage, then cl.exe just for compiling. So:
cpp.exe [options] source.c | mytool.exe > temp.c
cl.exe [options] temp.c
cpp.exe produces a file 5-10 times smaller than cl.exe /E. The trick is just to make it define _MSC_VER and similar instead of __GNUC__. I did this by using the -undef option to get rid of everything, then define MSFT specific ones manually. I may look into using clang as a CPP, since it can mimic MSVC.
CPP leaves the #pragma directives intact, so no problems with compatibility there.
I've now reached a performance point where the spawning of a process has a significant effect on the overall build time, so I'm looking into compiling a preprocessor into mytool.exe.
In Visual Studio 2010, under the Propererty pages, the Configuration Properties, a section for "Custom Build Step". Try this section.
Also search the internet for "MSDN Visual Studio custom build".