[llvm-dev] [RFC] LLVM Directory Structure Changes (was Re: [PATCH] D20992: [CMake] Add LLVM runtimes directory)

[Renato Golin via llvm-dev]

On 12 June 2016 at 00:35, Sean Silva via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>> I think the fundamental distinction needs to be following dependency
>> graphs because if we don’t get rid of the circular dependency in
>> bootstrapping there is no reason to make any changes.
>
> +1 for what Chandler said here.
>
> I don't think CMake itself per se cares about actual VCS repo breakdown. It
> should be possible to bring sanity without any change to VCS structure.

Funny enough "compiler-rt" is a fitting name to anything that provides
run-time libraries that users shouldn't be fiddling with, and that
includes builtins, sanitizers, profiling, the lot.

Not getting into the name and split bike shed, I agree with Sean that
this is a CMake issue, not a directory structure one.

Simply put, RT's CMake is a mess.

If we can build each component (builtins, sans, profs) independently,
then the overall build dependency can follow without a split, by
basically creating internal independent targets with a phony target
that builds them all being the default.

So, if in the main CMake you ask for libc++, RT and unwind, the build
dependency will be from specific internal targets in libc++ to other
internal targets in RT and so on.

This could also be a way out to separate the "builtins" target into
"builtins.<arch>" into different internal targets to allow
cross-compilation. Though, that'd requiring having a complete
toolchain for each of the supported target, so it can't be default on
the targets built in LLVM.

cheers,
--renato