I know this email is old and that I replied to your other email already, but I wanted to respond to this email too. Unfortunately you sent these emails while I was out of town and I’m just now catching up.
The CMake build system for compiler-rt is in the middle of a massive overhaul, and unfortunately I haven’t had as much time as I’d like to finish it off. Hopefully I’ll be getting the time to finish it off soon. Let me give you the high level view of where it is going.
The next big thing I’m trying to land is a restructuring of compiler-rt to logically separate the builtins and the sanitizer runtimes. I sent out a really early set of patches for this a while back you can find them here (http://reviews.llvm.org/D16653).
Once I finish that work, the next thing I’m going to be working on is overhauling how the LLVM build system interfaces with compiler-rt’s build. Today, when you build compiler-rt as part of LLVM it builds in one of two ways. The default (which is almost always wrong) is to build it using the host compiler and targeting the host. The alternative (by specifying -DLLVM_BUILD_EXTERNAL_COMPILER_RT=On to CMake) uses the just-built clang and targets the host, is at least sometimes right.
The problem is you actually may want to build compiler-rt more than once. To solve that problem we want to be able to specify a list of targets that can be passed to the LLVM build during configuration, which will tell compiler-rt which targets to build the builtins and sanitizers for. We also want to extend that mechanism to building libcxxabi, libcxx, and libunwind.
I’m really hoping to have most of this work done before the LLVM 3.9 release, but I might not get it done in time. It will mostly depend on how much my boss (and his boss) distract me. Since we’re all ADHD squirrels that could be a lot.
I mostly want you to know that I feel your pain, and there is actually effort being put in to fix it.
The other thing I wanted to touch on is you mentioned in your email you think there is a disconnect in mindset. I think you’re misunderstanding. The LLVM community supports very old OS versions. In fact, we still use CMake 2.8.12 because that’s what comes on the Ubuntu 14.04 LTS. I suspect we’ll be moving off that soon as there is a new LTS release imminent, but we generally support developing on 2-3 year old OS releases, and deploying to even older releases. As an example, in our coding standards document (http://llvm.org/docs/CodingStandards.html#supported-c-11-language-and-library-features) we list a significantly limited set of C++11 features that we allow in LLVM code. That list is catered based on supporting building with 3-5 year old compilers and running on some pretty old OS releases. In fact we just dropped running on Windows Vista and XP with the 3.8 release.
One of the complications with supporting old OS releases is that they aren’t always as well tested as the newer releases, and sometimes they get bugs that linger for a long time because none of the core developers really care. If there are bugs impacting your ability to use an older OS or toolchain, we will always accept patches to fix them as long as they’re reasonable and don’t introduce undue burden to the community (i.e. we’re not going to stop using C++11 because someone wants to support building with GCC 4.2).
If there are bugs preventing you from using clang on OS releases that are fairly modern but not cutting edge I’d encourage you to file bugs on our bug tracker (https://llvm.org/bugs/). Our community is committed to making Clang the best open source compiler around, and we generally hate it when users feel discouraged about our project.