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

[Renato Golin via libcxx-dev]

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.

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.

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