Ignore compiled FileCache class (all .pyo/.pyc files)
Fix using -Fonul parameter for no output file
Previously invoking clcahe would crash with following traceback when the size
of the output file was been determined for cache statistics:
Traceback (most recent call last):
  File "clcache.py", line 402, in <module>
  File "genericpath.pyo", line 49, in getsize
WindowsError: [Error 87] The parameter is incorrect: 'nul'
Correctly ignore the first parameter, which is the cl/cl.exe
Fix compiler output line endings.
For some reason compiler output had \0d\0d\0a as line endings, this changes them to
correct \0d\0a ones. This way sed eol matching, among other things, work correctly.
fix clcache.py to work with vs2008: read/expand cmd line parameters as utf-16 from input files referenced with '@'
revert changes to cl.exe invocation
redo changes to compiler invocation: pass original parameters to cl.exe
Merge remote-tracking branch 'frerich/master', knowingly overwriting all my changes to clcache.py.
- made clcache work with Visual Studio 2008 SP1
- modified printTraceStatement output format
- more trace messages
Ignore next argument after a -FI switch on the cl compile command line.
Add py2exe configuration to easily compile clcache to an executable.
Merge remote-tracking branch 'tmannerm/master'

Using merge strategy since I incorporated most of the fixes done in this
branch in some other form already. I'm doing this merge so that I can
see that I incorporated all changes in the commit graph.

The only two things I didn't understand yet (but didn't get a response
from the original author):

1. How to reproduce the issue addressed by
   819420901643293ba98b7920df36392ac626bac3
2. In which situations (with which compilers?) does
   ef43f1efd37b1f86138149319120f490385908c7 occur?
Fixed directory handling logic for /Fo

We only want to do the automagic directory handling logic if /Fo
was used to specify an output file name, since that's what cl.exe
does. The MSDN says about /Fo:

  This option specifies an object (.obj) file name or directory to be
  used instead of the default.

Without this patch, we would always implement this logic. So if you
did

  mkdir hello.obj
  cl /c hello.c

then a real compiler would bail out since it cannot open hello.obj
for writing, but we would compute the output file name
hello.obj/hello.obj.
Made parsing response files smarter

Don't just split on spaces but try to honour quotes. This may not
be exactly the right thing (since shlex tries to behave like a Unix
shell, but we need a Windows-style behaviour), but it's much better
already than just splitting on spaces.
Merge remote-tracking branch 'Popovich/master'

I believe I incorporated all improvements done in that branch in
one way or another, so let's do a "--strategy ours" so that I can see
that I have everything in here in the commit graph.
Merge remote-tracking branch 'jonastr/master'

I think I incorporated all the improvements done into this branch in my own
master branch by now, so let's do a merge with '--strategy ours' so that I can
see that I got all the work done here just by looking at the commit graph.
Bump copyright
Trying to lock cache directory consistently

Executing clcache.py in parallel might cause race conditions when
accessing the cache directory. All access to the cache directory
needs to be synchronized, so we need to implement some kind of
locking. Maybe I should rather use a simple SQL database or the
like which gets me ACID semantics for free...
Made findCompilerBinary() more robust in case we were frozen using py2exe

When using py2exe, it may well be that the user renamed the resulting
binary to 'cl.exe' so that it's a drop-in replacement. In that case,
we need to be more careful when trying to find the real compiler binary
because it's very well possible that the first cl.exe binary we find
is ourselves. If we used that, we'd invoke ourselves recursively.
Prefer using py2exe over a simple batch file

It seems that most people just compile to an executable to get a
drop-in replacement for cl.exe. Many build tools out there seem to get
a little confused in case the compiler binary is a batch file.