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

[Craig, Ben via llvm-dev]

I like this plan a lot.

The testing tools side of things is what makes compiler-rt cross 
compiling so much fun :).  You go through all sorts of trouble to make 
sure that the host compiler is ignored and that the cross compiler is 
the compiler that gets invoked, then the test infrastructure ends up 
needing the host compiler in addition the the cross compiler.  I think 
it's still a valuable problem to solve, but I also agree that it isn't 
trivial.


On 6/10/2016 12:52 PM, Chris Bieneman via llvm-dev wrote:
> It seems to me that the feedback here has been generally positive, but 
> a lot of different ideas have been added to the mix.
>
> To focus conversation and move things along I'm going to provide a 
> summary of changes with proposals for rollout.
>
> Splitting Compiler-RT
>
> If we want to split compiler-rt, which I think makes a lot of sense, I 
> think the best path forward is to copy the trunk (via svn cp). Copying 
> the branch is the best way to preserve the history and workflows.
>
> For naming purposes I would suggest retaining the compiler-rt name for 
> the builtin libraries, and having a repository named sanitizer-rt for 
> the sanitizer libraries (this is of course just a suggestion, feel 
> free to bike shed).
>
> After duplicating the repository we could setup an auto-merge from 
> compiler-rt to sanitizer-rt. We could setup the LLVM build system so 
> that if both projects were present it would force only building 
> builtins from compiler-rt and sanitizers from sanitizer-rt. This would 
> allow a transition time where bots could be updated to include both 
> repositories, and engineer workflows would not be impacted.
>
> After a brief time for bots to be updated with the new repository we 
> could modify the repositories separately to build only the parts they 
> are supposed to build, remove the hack from LLVM to force that, and 
> begin removing code from the separate repositories.
>
> LLVM Restructuring
>
> The first step here is adding the new functionality, iterating on the 
> CMake interface for the runtime projects and getting all the runtime 
> projects hooked up.
>
> Once all the runtime project support is ready we can begin migrating 
> bots and evangelizing the new runtime build process.
>
> At some point before or after the runtime work we can modify CMake to 
> support the test-suite living under tests (or somewhere else, bikeshed 
> away).
>
> Once runtime support is ready, and the test-suite is supported outside 
> projects we can set a date for removal of the projects directory. This 
> planning should take into account updating bots as well as updating 
> scripts and tooling.
>
> Breaking out testing tools
>
> As I started looking into breaking out the testing tools I realized it 
> is *much* more complicated than I had first thought. I do think that 
> it is a good idea to do this, but it is going to be a bigger change 
> than I had originally thought.
>
> The big wrench in breaking out the testing tools is that you need more 
> than just lit. In particular you need FileCheck, not, count and a few 
> other random things under llvm/utils. This also means you need to 
> break out libSupport and ADT.
>
> While I think that breaking this stuff all out is a good idea, it is a 
> much larger change than what I was trying to propose. If we go down 
> this route I would recommend creating a new llvm-infrastructure 
> repository. We could then stub it out and update projects and 
> workflows to include it. After the workflows are updated we can start 
> moving libraries and tools into it.
>
> An alternative approach we could take would be to migrate the testing 
> tools off libSupport to make them standalone. Then the testing tools 
> and lit could more easily be lifted out of the LLVM repository. This 
> approach has some benefits, but also has added complication because 
> some of the libSupport functionality in use is non-trivial.
>
> Thoughts?
> -Chris

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project