I can think of several:
- When the Clang CMakefiles go to build compiler-rt (if present), they use the compiler used to build Clang and not the newly-built Clang itself.
This one is fairly minor (I think), but it does make CMake as it stands untenable for cross-compilation builds where the host and target are not the same--the compiler-rt libs get built for the *host* and not for the *target*. But as you pointed out, there is a workaround (albeit a clumsy workaround).
Just something to keep in mind if and when you do move to CMake.
- CMake is not available everywhere. Bourne shells are*.
As I recall, this is the reason autoconf generates shell scripts: because nearly every operating system out there comes with a shell! Even the old-timey MPW development environment for the Mac came with one! (* Even Windows comes with a shell, though it's not a Bourne shell but something else entirely with a few constructs borrowed from the Bourne shell's predecessor, the Thompson shell. But I only care about Windows inasmuch as people still use it anyway.)
In particular, CMake is not distributed with Xcode. This means that engineers at Apple--who may I remind you all still drives the bulk of LLVM, Clang, and especially LLDB development, though IBM, Intel, AMD, and especially Google have really stepped up their contributions recently--and for whom you yourself, Eric, once worked until somewhat recently--won't be able to build their own shiny new toolchain at all, unless they can somehow convince management to install CMake. In fact I seem to recall quite recently someone from Apple (Jim Ingham?) on one of the LLVM lists complaining that he wanted to use ninja, but couldn't because he couldn't get ninja and CMake installed on his workstation. Until this changes--and good luck with that--expect heavy resistance from anyone still at Apple (other than Doug Gregor, of course :).
- Some people around here don't like CMake very much, if at all--Daniel Dunbar, I'm looking at you!
I've brought this up before, but I distinctly recall Daniel saying he had some kind of plan for making a new Python-based build system for LLVM. Those LLVMBuild files scattered throughout the tree? That was supposed to be the start of it. I don't know if he's abandoned those plans or what, but I think we should consider all our options before we commit to CMake. (Then again, Python isn't exactly everywhere either. It's more widely distributed than CMake--Mac OS X and damn near every Linux distro comes with it--but again, Windows doesn't come with it either. And I recall some other people raising objections to a Python build system because of that...)
Heck, I'll admit that *I* don't like CMake that much, either. It's certainly better than "autohell" (as one person on this list put it), I'll give it that. But I think we can do better than CMake. Granted, CMake is the easiest alternative to autoconf, since we have most of the infrastructure for it in place already, but what will we do when sometime (5, 10 years?) down the line we find that CMake is inadequate and want to move off of it? This--the beginning of the next release cycle, as others have pointed out--is exactly the right time to consider alternative build systems so we can work the bugs out of them in time for 3.4.
Now if you'll excuse me, I need to go put on a flame-retardant suit...
Chip
