I'll take a look at this later. I would just merge it now, but a few points / questions:

• CMake "best practice" is to do out-of-source builds, so Disallow in-source builds with CMake. #23 will enforce that -- and .gitignore will not be necessary; if it's all the same to you I'm leaving that out.
• I was going to eliminate all platform-specific project files, except in tags, in favor of the CMake file. Do you think that's a bad idea? (If so then obviously .gitignore comes back for Visual Studio temporary files.)
• Regarding the snprintf problem, this actually makes me rethink my implementation on Changed sprintf to snprintf in MemoryOutStream::FormatToStream. #28. Perhaps I need to use format strings to limit the size instead and go back to sprintf.

Thanks.

Hey Patrick,
I just wanted to add my opinion to your second bullet point: I do think it is a bad idea to remove VS project files for reasons similar as those I stated in comments of 259cf50 regarding autoconf. Various reasons could push people away from CMake including not being familiar with it, CMake being buggy/unsupported on a given platform, or just laziness.
I do think CMake is a great tool and should be more used but not offering people alternatives will only result in less people using unittest++. In addition to that, there might already be distribution packages built around the current build systems (at least, the Gentoo ebuild uses autoconf), and deleting it will cause a lot more work to package maintainers or make it unavailable on a platform (if CMake is buggy).
On the other hand, I also understand that supporting many different build system is impractical, so my vote goes for officially supporting CMake and leave it to contributors to support other build systems if they need them.

This sounds like good advice @qdii, I had concerns about taking that path anyway. For the moment I'll accept this pull and then I'll probably rejigger some things in the near term.

My preference would be GYP. Have a central gyp file and build all projects (all VS flavors and any other, like make) from that. I would even go so far and keep the generated files in the source tree. But that is just my opinion.

I took a look at GYP and, personally, found it gross. ;) Not that CMake is a beautiful butterfly.

Soon I'll have my full test setup up and running and I'll be able to generate fresh project files CMake without leaving in the dependency on CMake.

Ok I don't know what part of GYP you found gross. I think it is a diamond in the rough, it is great... except it needs a full installation of python. Then again it was a while since I have seen CMake; may learn something.

Aside from the problem of having Yet Another Meta Build System, GYP's own docs says this about its own objectives,

When in doubt, do what Chromium needs and don't worry about generalizing the solution.

While CMake is also gross in some sense (its language is pretty rough), it does some things really well and its intended to be a generalized solution. It's become somewhat of a standard solution.

It's become somewhat of a standard solution.

Can't argue with that.