[llvm-dev] RFC: A top level monorepo CMake file

[Louis Dionne via llvm-dev]

> On Jun 18, 2020, at 14:44, Renato Golin <rengolin at gmail.com> wrote:
> 
> Hi Louis,
> 
> I think that's a good cleanup, will make things more "reasonable",
> especially for new developers and may clean up a lot of the CMake
> dependencies we have.
> 
> However, it will touch most (every?) sub-project, and have marginal
> benefits other than "feeling nice".
> 
> Furthermore, some of the problems you describe below can already be
> fixed without changing the root CMake file. Maybe not as cleanly, but
> close enough.

I disagree. The root cause of the problem is that including <monorepo-root>/llvm/CMakeLists.txt is equivalent to asking to compile LLVM for the target we're targeting. However, this may simply not make sense for some target platforms, where one would never build a compiler for that target. I guess we could add conditionals to guard parts of llvm/CMakeLists.txt (and children of it) so that it appears to work on all targets we care about, but that would just be adding complexity to llvm/CMakeLists.txt, when what we *really* want to do is just bypass its CMake configuration altogether.

> 
> So, while I commend your effort, I think an easier approach would be
> to slowly fix the more critical problems in our usage of CMake and
> then move the root.

I think we both need to fix our CMake usage (like global variables, global flags setting and other anti patterns), and also allow bypassing projects that we don't want to build. I suspect the only reason why things were set up inside llvm/CMakeLists.txt is that historically, there was simply no monorepo root we could add a CMake file to. If there had been one, I strongly suspect things would have been the way I describe since the start.

That being said, I agree the changes I suggest need to be done step by step, and that's the way I planned on doing it if we get consensus.

Louis

> 
> On Thu, 18 Jun 2020 at 18:57, Louis Dionne via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> I'm not sure about other projects, however this is quite problematic for projects part of the C++ runtime (libc++/libc++abi/libunwind). Indeed, we often try to build those projects targetting not widely supported platforms, where the overall LLVM build doesn't work. For example, trying to use the LLVM_ENABLE_PROJECTS approach for building libc++ for Apple's DriverKit environment doesn't work, since it has a few unusual things that the LLVM build chokes on. However, building libc++ standalone works just fine because it has far fewer requirements. It's also not just an issue of working vs not working: because of global flag pollution, building libc++ standalone and as part of the rest of LLVM can result in slightly different flags being used, which could cause important and hard-to-diagnose issues.
> 
> In the end, we'll have to make sure it works for all existing builds,
> upstream and downstream, and that's not trivial. That's why I
> recommend we do one small step at a time.
> 
>> What I'm proposing isn't a replacement for itl. The "Runtimes" build can be seen as a driver that sets up the individual libc++/libc++abi/libunwind builds with the just-built toolchain, and for the provided targets. That's really great, however it is built *on top of* the basic libc++/libc++abi/libunwind builds. So basically, after my proposal, the "Runtimes" build could simply build all elements from the runtime with a single CMake invocation, as opposed to multiple invocations.
> 
> Essentially, we may want to build the runtimes stand-alone, or
> multiple variations when selecting multiple targets_to_build, and
> that's not trivial. It would be good if we could join the
> infrastructure into one place and do it right. While not a requirement
> for your proposal, I fear it will create too many unforeseen problems
> as is.
> 
> cheers,
> --renato