There are so many, in fact, that choosing one becomes a confusing array of choices in itself.

Use cmake, no fuck this, try JAM. WTF? Why not simple Makefiles, better yet manually written projects for XCODE, VCPROJ.... Oh fuck no.... At the end of the day you wrote something to get your shit out. Simple as that :)

Just google for "msvcrt_win2000.obj" and see the madness (yes, it's about using MSVCRT.DLL instead of later MSVC libs, and still get your shit working on 2000 or XP). I did that just last few hours :)

If you statically link, will it only run on the latest platform? I don't believe I've ever shipped an app that dynamically linked to the MSVCRT.

It can, and that's what I did. But I decided to experiment, and there is some little benefit - less memory usage, and supposedly malloc() from one place can be freed() by another (or I think so). A lot of Microsoft products are still linking to it. At work we don't care and link to whatever latest MSVC provides, but for certain products to write plugins we have to use the exact same Visual Studio version (for example Autodesk Maya or MotionBuilder).

There are way too many subtle details (and more complicated with Windows's manifests, side by side assemblies and crap like that).

Hah! Exactly.

There is one that I can recommend, for the record, at least for C++:

Qt's QMake.

QMake can be quite helpful. Unfortunately, it may not be a good long-term choice:

http://labs.qt.nokia.com/2009/10/14/to-make-or-not-to-make-q...

http://lists.qt.nokia.com/pipermail/qt5-feedback/2011-May/00...

The last project I tried that used qmake missed dependencies on generated files, and therefore needed make clean fairly often.

It's sad, but the best user experiences I've had were either hand-coded makefiles, or autotools (ick).