[cfe-dev] Small patches to allow fully independent clang/llvm/compiler-rt/libc++

[C Bergström via cfe-dev]

On Wed, Oct 14, 2015 at 8:11 PM, Vasileios Kalintiris
<Vasileios.Kalintiris at imgtec.com> wrote:
>> Some people may disagree on the principle, even if it doesn't affect
>> current builds. But I'll let them voice their concerns.
>
> IMHO, the "correct" approach for a GNU-free/independent clang package requires
> a new ToolChain class for LLVM-based toolchains. Maybe, this class could
> inherit from the Linux ToolChain and use most of the existing infrastructure
> for paths, options & tools invocations. Otherwise, we could use these
> configuration-time options for most of the GNU-dependencies that we want to
> replace. However, I think that we would be duplicating effort/functionality
> at two different places (cmake & clang source code). Additionally, other than
> compiler-rt, libcxx, libcxxabi, etc., we'd need a non-GLIBC/GNU C library
> which might have a different set of CRT files with its own naming scheme for the
> dynamic linker/loader.
>
> Having said all that, I don't explicitly disagree with these set of patches.
> They could offer a reasonable trade-off for the time being.

Actually..... I agree with you and I'm not sure if it's exactly what
you're referring to, but could be along those lines
https://github.com/pathscale/llvm-suite/

The above is mostly a convenience cmake "wrapper" or parent project
which helps glue everything together so that with a single cmake you
can build and configure the whole thing at once. Internally we handle
the CRT problem, but I'm not sure if the above does. (I'd have to
double check, but it would also probably require more clang driver
changes as well)

One of the things I personally like about the above is that it allows
the "just built" clang to then build the runtimes. That way if you
statically link clang - there's no dependency on the host system.
(Barring libc, but that's typically future compatible. I've tested
this all the way back to SLES10)

If the patches get pushed upstream I plan to start nightly builds of
GNU free packages across many platforms (Solaris, Win, OSX, Linux and
various targets) My goal is to help make it easier for people in the
community to test nightly packages instead of having to build it. (At
all users can or want to build the whole thing)

Lastly - with a bit of modification the above also allows you to do
native and cross compiler builds at the same time/same package. (Lets
call that phase 2)