RFC: A top level monorepo CMake file

Hi folks,

Building any LLVM project currently requires invoking CMake inside /llvm, while setting the projects to enable in the LLVM_ENABLE_PROJECTS variable. This has the downside that CMake processing for the LLVM subproject happens even when one doesn’t really need or want it. It’s also not great from a build hygiene perspective, as LLVM globally sets some flags and subprojects pick them up, when they don’t really mean to. For example, see this workaround: https://github.com/llvm/llvm-project/blob/master/libcxx/CMakeLists.txt#L503-L507, where we need to account for some flags that might have been set globally by LLVM.

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.

Hence, I think we should introduce a way to build LLVM projects (or at least the runtimes) without going through /llvm/CMakeLists.txt. What I suggest is to have a top-level /CMakeLists.txt whose sole job is to include subprojects. We could also place basic LLVM-wide things like the check for the minimum CMake version there. More specifically, I would like to be able to do:

$ cd
$ mkdir build
$ (cd build && cmake -DLLVM_ENABLE_PROJECTS=“”)

Pretty much the only difference with today is that you’d use cmake <monorepo-root> instead of cmake <monorepo-root>/llvm.

Like I said, this is a problem for the runtime projects, but I’m not sure about other projects. For the runtime projects, another option would be to only allow standalone builds. However, the runtime projects are often built in lockstep, and so running three CMake commands when one would suffice is both annoying and also an easy way to screw things up. Furthermore, the current standalone builds add complexity to the projects, because they require the ability to point to arbitrary headers/libraries from the other projects, when we really always want to point to the just-built ones.

Relationship with Petr Hosek’s “Runtimes” build

Hi folks,

Building any LLVM project currently requires invoking CMake inside <monorepo-root>/llvm, while setting the projects to enable in the LLVM_ENABLE_PROJECTS variable. This has the downside that CMake processing for the LLVM subproject happens even when one doesn't really need or want it. It's also not great from a build hygiene perspective, as LLVM globally sets some flags and subprojects pick them up, when they don't really mean to. For example, see this workaround: https://github.com/llvm/llvm-project/blob/master/libcxx/CMakeLists.txt#L503-L507, where we need to account for some flags that might have been set globally by LLVM.

Just pointing out: processing the llvm directory is not really a
problem for the libc project as it uses LLVM support libraries for
build tooling and testing.

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.

Hence, I think we should introduce a way to build LLVM projects (or at least the runtimes) without going through <monorepo-root>/llvm/CMakeLists.txt. What I suggest is to have a top-level <monorepo-root>/CMakeLists.txt whose sole job is to include subprojects. We could also place basic LLVM-wide things like the check for the minimum CMake version there. More specifically, I would like to be able to do:

I suppose vars like LLVM_CXX_STD_default will also be set up in the
higher level CMake file.

    $ cd <monorepo-root>
    $ mkdir build
    $ (cd build && cmake <monorepo-root> -DLLVM_ENABLE_PROJECTS="<projects-to-enable>")

Pretty much the only difference with today is that you'd use `cmake <monorepo-root>` instead of `cmake <monorepo-root>/llvm`.

Will rules like add_tablegen, add_llvm_library etc continue to work
without any changes?

I like the proposal but I would like to go even further. If we are going to create a top level CMake file, we should just go ahead and eliminate all the standalone build configuration. The standalone build should just be cmake <monorepo-root> -DLLVM_ENABLE_PROJECTS=standalone-project .... That means less build configuration to maintain which is always good.

That also means that we can refactor some of the cmake modules to put into the top level directories so sub-projects can just reuse them without duping the code worrying they are not available in the standalone build today.

Steven

Hi folks,

Building any LLVM project currently requires invoking CMake inside <monorepo-root>/llvm, while setting the projects to enable in the LLVM_ENABLE_PROJECTS variable. This has the downside that CMake processing for the LLVM subproject happens even when one doesn't really need or want it. It's also not great from a build hygiene perspective, as LLVM globally sets some flags and subprojects pick them up, when they don't really mean to. For example, see this workaround: https://github.com/llvm/llvm-project/blob/master/libcxx/CMakeLists.txt#L503-L507, where we need to account for some flags that might have been set globally by LLVM.

Just pointing out: processing the llvm directory is not really a
problem for the libc project as it uses LLVM support libraries for
build tooling and testing.

Good to know -- I was talking loosely about "runtime projects", but really I meant libc++, libc++abi and libunwind, since that's what I know best. If the issues I described don't apply to other projects, it may be reasonable to go for a more local solution too.

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.

Hence, I think we should introduce a way to build LLVM projects (or at least the runtimes) without going through <monorepo-root>/llvm/CMakeLists.txt. What I suggest is to have a top-level <monorepo-root>/CMakeLists.txt whose sole job is to include subprojects. We could also place basic LLVM-wide things like the check for the minimum CMake version there. More specifically, I would like to be able to do:

I suppose vars like LLVM_CXX_STD_default will also be set up in the
higher level CMake file.

No, I don't think that makes sense. Different project may decide to build with different standard versions. Actually, modern CMake advocates for the standard to be set on a per-target basis.

This is really important -- for example changing the standard we build libc++ with might have ABI implications, so we need to be careful and explicit about changing it. I don't think it makes sense to be decided at such a high level.

   $ cd <monorepo-root>
   $ mkdir build
   $ (cd build && cmake <monorepo-root> -DLLVM_ENABLE_PROJECTS="<projects-to-enable>")

Pretty much the only difference with today is that you'd use `cmake <monorepo-root>` instead of `cmake <monorepo-root>/llvm`.

Will rules like add_tablegen, add_llvm_library etc continue to work
without any changes?

I would suggest they don't by default, however we could extract common CMake functionality into files that subprojects can include. Basically, we could have <monorepo-root>/cmake/foo.cmake.

Louis

I like the proposal but I would like to go even further. If we are going to create a top level CMake file, we should just go ahead and eliminate all the standalone build configuration. The standalone build should just be cmake <monorepo-root> -DLLVM_ENABLE_PROJECTS=standalone-project .... That means less build configuration to maintain which is always good.

That also means that we can refactor some of the cmake modules to put into the top level directories so sub-projects can just reuse them without duping the code worrying they are not available in the standalone build today.

Yes, I fully agree. I would do it in a staged way to avoid breaking people, but I agree that a couple months down the road, we should have exactly one way of building any given runtime – through the top-level CMake file.

Louis

I like the proposal but I would like to go even further. If we are going
to create a top level CMake file, we should just go ahead and eliminate
all the standalone build configuration. The standalone build should just
be `cmake <monorepo-root> -DLLVM_ENABLE_PROJECTS=standalone-project
...`. That means less build configuration to maintain which is always good.

This would break the release of standalone source tarballs, no?

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.

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

I like the proposal but I would like to go even further. If we are going
to create a top level CMake file, we should just go ahead and eliminate
all the standalone build configuration. The standalone build should just
be `cmake <monorepo-root> -DLLVM_ENABLE_PROJECTS=standalone-project
...`. That means less build configuration to maintain which is always good.

This would break the release of standalone source tarballs, no?

I guess it would, however they are already broken at least for libc++, libc++abi and libunwind. These projects don't support being built outside of the monorepo layout. They require many similar things and share a lot of code, and we've started implementing nice simplifications since we agreed to require the monorepo layout.

IMO, this is an unavoidable (nice) consequence of moving to the git monorepo.

Louis

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

I like the proposal but I would like to go even further. If we are going
to create a top level CMake file, we should just go ahead and eliminate
all the standalone build configuration. The standalone build should just
be `cmake <monorepo-root> -DLLVM_ENABLE_PROJECTS=standalone-project
...`. That means less build configuration to maintain which is always good.

This would break the release of standalone source tarballs, no?

That is a problem we can fix. We just need to ship those tarballs with some processing by including the top-level cmake and cmake modules, and removing all other subdirectories.
I don't think we have split standalone repo so it is just about release management. Yes, all the clients will have to build standalone projects differently so it is a workflow break but it should be acceptable.

Steven

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.

Some of them, not the big one. :slight_smile:

For example, the split between projects and runtime for the libraries
and their complicated dependencies between each other.

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.

Monorepo is new, sure, but before that, we still had to link
directories in specific places inside /llvm to compile stuff. It was
more because "llvm was the root CMake" than multi/mono repo. LLVM was
the first, and others started to appear and re-use the infrastructure
instead of replicating, that's why the mess.

I am in favor of this change because having the “root” CMakeLists.txt be in the llvm subfolder breaks some IDEs. Specifically, if you try to use Visual Studio’s CMake integration, you will only see the llvm subproject in the file browser pane. Visual Studio works fine if you manually generate and MSBuild project, but I keep hearing about how much faster everything is with Ninja, and this is a major issue that prevents me from trying to use it.

Thanks,

Christopher Tetreault

I am in favor of this change because having the “root” CMakeLists.txt be in the llvm subfolder breaks some IDEs. Specifically, if you try to use Visual Studio’s CMake integration, you will only see the llvm subproject in the file browser pane. Visual Studio works fine if you manually generate and MSBuild project, but I keep hearing about how much faster everything is with Ninja, and this is a major issue that prevents me from trying to use it.

I'm glad to hear the proposed change would help in that area as well!

Louis

I like the proposal but I would like to go even further. If we are going to create a top level CMake file, we should just go ahead and eliminate all the standalone build configuration. The standalone build should just be `cmake <monorepo-root> -DLLVM_ENABLE_PROJECTS=standalone-project ...`. That means less build configuration to maintain which is always good.

Eliminating stand-alone builds would be an inconvenience for
us in Fedora, since this is how we build LLVM packages.
However, I think we may have different definitions of what a
stand-alone build is.

Does your proposal mean that
`cmake <monorepo-root> -DLLVM_ENABLE_PROJECTS=lld ..` would build lld
only without llvm and be a replacement for what I consider to
be a stand-alone build, which is `cmake <monorepo-root>/lld ...`

-Tom

+1 for this change.

Hi folks,

Building any LLVM project currently requires invoking CMake inside /llvm, while setting the projects to enable in the LLVM_ENABLE_PROJECTS variable. This has the downside that CMake processing for the LLVM subproject happens even when one doesn’t really need or want it. It’s also not great from a build hygiene perspective, as LLVM globally sets some flags and subprojects pick them up, when they don’t really mean to. For example, see this workaround: https://github.com/llvm/llvm-project/blob/master/libcxx/CMakeLists.txt#L503-L507, where we need to account for some flags that might have been set globally by LLVM.

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.

Hence, I think we should introduce a way to build LLVM projects (or at least the runtimes) without going through /llvm/CMakeLists.txt. What I suggest is to have a top-level /CMakeLists.txt whose sole job is to include subprojects. We could also place basic LLVM-wide things like the check for the minimum CMake version there. More specifically, I would like to be able to do:

$ cd
$ mkdir build
$ (cd build && cmake -DLLVM_ENABLE_PROJECTS=“”)

Pretty much the only difference with today is that you’d use cmake <monorepo-root> instead of cmake <monorepo-root>/llvm.

Like I said, this is a problem for the runtime projects, but I’m not sure about other projects. For the runtime projects, another option would be to only allow standalone builds. However, the runtime projects are often built in lockstep, and so running three CMake commands when one would suffice is both annoying and also an easy way to screw things up. Furthermore, the current standalone builds add complexity to the projects, because they require the ability to point to arbitrary headers/libraries from the other projects, when we really always want to point to the just-built ones.

Relationship with Petr Hosek’s “Runtimes” build

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.

I think there may be a misunderstanding of how the “runtimes” build work. It already uses an equivalent of:

cmake -DCMAKE_CXX_COMPILER= -DCMAKE_CXX_COMPILER=<path to just built clang++> -DLLVM_ENABLE_PROJECTS=“libcxx;libcxxabi;libunwind”

The reason why it doesn’t do exactly that is because LLVM’s root CMakeLists.txt does too many things, and doesn’t do some of the things we need.

Instead we use a trick where llvm/runtimes/CMakeLists.txt re-invokes itself for different targets. When invoked as a the root file it drives the build for all runtimes, resembling the CMake invocation above, but it also exposes a “build API” to the parent build, so as the user of the “runtimes” build, you use the parent build and it drives the child builds through this API.

When using runtimes build, you have to make one CMake invocation to build tools, and then one CMake invocation per-target to build runtimes (but not one CMake per project). I don’t think there’s a way to get down to a single CMake invocation unless CMake gains support for “scoped toolchains” (today there’s only one global host toolchain), which is something that GN has and why in GN this is possible.

I don’t think that having a top-level CMake file changes anything for the “runtimes” build. We could consider merging llvm/runtimes/CMakeLists.txt into the top-level CMake file, but I don’t see any immediate gains aside from clearer file structure.

I think a bigger win, and not just for the runtimes build, would be to have a global CMake modules directory that would be shared by all subprojects avoiding the duplication we currently have, and allow sharing cached variables between runtimes which should significantly reduce the number of CMake checks we have to run. For example, today every runtime does the same set of checks to ensure your system has libc, libm, pthreads, etc. We really should only ever have to run those once per CMake invocation.

I like the proposal but I would like to go even further. If we are going to create a top level CMake file, we should just go ahead and eliminate all the standalone build configuration. The standalone build should just be `cmake <monorepo-root> -DLLVM_ENABLE_PROJECTS=standalone-project ...`. That means less build configuration to maintain which is always good.

Eliminating stand-alone builds would be an inconvenience for
us in Fedora, since this is how we build LLVM packages.
However, I think we may have different definitions of what a
stand-alone build is.

Does your proposal mean that
`cmake <monorepo-root> -DLLVM_ENABLE_PROJECTS=lld ..` would build lld
only without llvm and be a replacement for what I consider to
be a stand-alone build, which is `cmake <monorepo-root>/lld ...`

Let me clear up the terminology here. In current llvm-project, we have a full build and standalone build. Let say for libcxx (using libcxx or other runtime libraries because they can build without anything from llvm subdirectory).

This is a full build that can produce libcxx dylib:
`cmake <monorepo-root>/llvm -DLLVM_ENABLE_PROJECTS=llvm;libcxx -DLLVM_DISTRIBUTION_COMPONENTS=libcxx.dylib ...`

This is a standalone build that doesn't pull in anything from llvm directory:
`cmake <monorepo-root>/libcxx -D...`

Those two cmake configurations are going down different path and can result in different behavior if not careful. The goal is just turning those into one configuration. You can still do a standalone build of runtime library by enabling just that project and it is going to produce the same build configuration as the full build.

Steven

I like the proposal but I would like to go even further. If we are going to create a top level CMake file, we should just go ahead and eliminate all the standalone build configuration. The standalone build should just be cmake <monorepo-root> -DLLVM_ENABLE_PROJECTS=standalone-project .... That means less build configuration to maintain which is always good.

Eliminating stand-alone builds would be an inconvenience for
us in Fedora, since this is how we build LLVM packages.
However, I think we may have different definitions of what a
stand-alone build is.

Does your proposal mean that
cmake <monorepo-root> -DLLVM_ENABLE_PROJECTS=lld .. would build lld
only without llvm and be a replacement for what I consider to
be a stand-alone build, which is cmake <monorepo-root>/lld ...

Let me clear up the terminology here. In current llvm-project, we have a full build and standalone build. Let say for libcxx (using libcxx or other runtime libraries because they can build without anything from llvm subdirectory).

This is a full build that can produce libcxx dylib:
cmake <monorepo-root>/llvm -DLLVM_ENABLE_PROJECTS=llvm;libcxx -DLLVM_DISTRIBUTION_COMPONENTS=libcxx.dylib ...

This is a standalone build that doesn’t pull in anything from llvm directory:
cmake <monorepo-root>/libcxx -D...

Those two cmake configurations are going down different path and can result in different behavior if not careful. The goal is just turning those into one configuration. You can still do a standalone build of runtime library by enabling just that project and it is going to produce the same build configuration as the full build.

Can you clarify what is going to be built with `cmake -DLLVM_ENABLE_PROJECTS=libcxx ?

We need to cross-compile the libraries using the pre-installed clang in SDK and have to use the standalone builds i.e. cmake /libcxx. We do not wish to rebuild llvm or clang when cross-compiling the libraries.
If cmake -DLLVM_ENABLE_PROJECTS=libcxx is going to build more than libcxx, it is a big no-go for us (Chrome OS). Same for other libraries like libcxxabi/libunwind.

Also, we do not currently link libc++ with llvm’s libunwind as it misses many functionalities provided by libgcc_s/libgcc_eh in particular on ARM32 (related to GCC/GLIBC extensions) and ARM was not willing to invest in that.
So, whilte it’d be nice to build libc++abi/libc++/libunwind in a single innovation, linking with libunwind should NOT be mandatory.

Thanks,
Manoj

I like the proposal but I would like to go even further. If we are going to create a top level CMake file, we should just go ahead and eliminate all the standalone build configuration. The standalone build should just be `cmake <monorepo-root> -DLLVM_ENABLE_PROJECTS=standalone-project ...`. That means less build configuration to maintain which is always good.

Eliminating stand-alone builds would be an inconvenience for
us in Fedora, since this is how we build LLVM packages.
However, I think we may have different definitions of what a
stand-alone build is.

Does your proposal mean that
`cmake <monorepo-root> -DLLVM_ENABLE_PROJECTS=lld ..` would build lld
only without llvm and be a replacement for what I consider to
be a stand-alone build, which is `cmake <monorepo-root>/lld ...`

Let me clear up the terminology here. In current llvm-project, we have a full build and standalone build. Let say for libcxx (using libcxx or other runtime libraries because they can build without anything from llvm subdirectory).

This is a full build that can produce libcxx dylib:
`cmake <monorepo-root>/llvm -DLLVM_ENABLE_PROJECTS=llvm;libcxx -DLLVM_DISTRIBUTION_COMPONENTS=libcxx.dylib ...`

This is a standalone build that doesn't pull in anything from llvm directory:
`cmake <monorepo-root>/libcxx -D...`

Those two cmake configurations are going down different path and can result in different behavior if not careful. The goal is just turning those into one configuration. You can still do a standalone build of runtime library by enabling just that project and it is going to produce the same build configuration as the full build.

What does libcxx currently need that is in the llvm directory?

-Tom

The proposal I have has nothing to do with you can build and what you will be. Nothing is changed. Maybe the terminology standalone/full build is misleading.

The correct term is probably a full configuration (requires llvm subdirectory) vs standalone configuration (with only project’s own subdirectory). I would like to see them become one to avoid maintenance cost and mistakes.

Steven

FWIW: +1 for me.

I actually looked into doing this a couple of times already, but too many things are tangled for me to manage it, in particular around the runtimes. Having someone who understands the runtime situation driving it would make sense.
I think I also tried to do “too much at once” instead of a sequence of smaller NFC refactorings to get closer to the desired state.