How to run individual phases of a 2 or 3-stage build?

I am trying to bootstrap Clang/LLVM 11.0.1, using the Fuchsia CMake cache files as my template to work from.

However, it doesn’t properly build the libraries of the various targets I am giving it.

Now it would be great if I could somehow debug this issue without re-running this as a fully integrated build every time. So I was wondering if there was a way to use the stage 1 Clang which gets built during the process, but essentially redo everything starting from there (assuming that cmake gets called again after that Clang is built and in place).

So ideally I’d like to be able to get my build folder into a state that resembles the state directly prior to invoking stage 2 and then redo stage 2 over and over again, debugging my issues in the process.

Thanks for any insights you can offer.


Replying to myself a little (yeah, I’m crazy like that) …

Okay, so ninja offers a few ways to navigate the dependencies. My new favorite is certainly ninja -t browse <target> :wink:

This was the way how I discovered at least in part what I was looking for. In order to complete stage 1 one can apparently use clang-bootstrap-deps (which sort of translates to “all the dependencies required to build stage 2”).

Originally I was building stage2-install-distribution-stripped which implied clang-bootstrap-deps, but obviously didn’t stop after that step.

In order to proceed from that point one can cmake --build . --target stage2-configure (from within the build directory) and subsequently the same with target stage2-build. Interestingly in my case stage2-build appears to build more than stage2-install-distribution-stripped. I guess the distribution simply contains less than the “full build” or some such.

Anyway, in order to investigate all of the different files one can simply search for them, change into the directory with them (respectively) and use ninja -t browse once again. Relative to the (CMake) build directory I found:

  • ./
  • ./tools/clang/stage2-bins/
  • ./runtimes/builtins-bins/
  • ./runtimes/runtimes-bins/

Another curious thing was that the real targets often follow a hierarchical naming convention like tools/clang/stage2-stamps/stage2-install-distribution-stripped, and a phony target without the “prefix” exists for convenient access to those targets.

My CMake-fu is probably not as strong as that of many in the LLVM community, but I get along and these findings about Ninja was certainly eye-opening.

As I discover more, I’ll amend this thread in the hope that it helps someone else (or myself in a few months from now :wink:).