It has taken me a long time, but I have moved over to using CMake as an pseudo-build step. The basic premise of the system is that it will generate platform specific development files for the particular flavor of development environment available on that platform. For instance, it will generate xCode projects when I am working on the Mac or for the iPhone, but it will also generate Visual Studio files for when I am working on the PC. However, for obvious reasons, it must deal with many of the issues that come with having to support only the lowest common denominator in terms of basic configurations. Specifically, if you go this route, multi-platform support is not supported. So you will not be able to have a single solution for both your x64 and x86 code when working with Visual Studio. I decided that this was acceptable once I started having to work between Visual Studio and xCode as part of my weekly process to validate code across both platforms and different compilers. I could try to maintain two sets of projects, but this starts to become and incremental nightmare. For instance, some of the best ways to develop SPU code is by running Linux on the PS3 (I have retained a single PS3 retail kit at the correct version so that I can continue doing this - I wanted to buy a slim version anyway and it was a good excuse). I would of course like to be able to compile at least some of my files and systems easily for this, and that would require maintaining makefiles in parallel as well. Now we are up to three different project definition files that need to be maintained. Well that is not going to happen. The final thing that pushed me over the edge was reading someone else’s blog (forget the name actually) where he called out solution and project files as intermediate files - that there only real purpose was to allow the user to interact with their source files. Once you stop thinking of these files as part of the source, but instead just a management layer - then making the move to where they are generated from another process is easy to do.
Everything is not roses though - I had to make some changes to the CMake source (its open source) to provide all the support that I needed. However, this was easy to do as much of there configuration is based on a STL map, and the configuration files can add arbitrary text properties to a file. This allowed me to fix the few things I needed to add by creating my own (and new) file properties. My specific problem was needing to turn off the use of PCHs on a per file basis (instead of the project level). I need to do this since most of my project is ANSI-C standard, but I was unable to compile the Windows header files with these settings as they depend on MS specific extensions. The solution was to compile the three C files that require those headers without the use of PCHs so that the rest of the files would use the ANSI-C standard PCH. The other issue was that CMake does not differentiate as well as Visual Studio between source, intermediate and target directories. I had to expand some support so that my compilation environment would be properly supported.