Speaking on how to locate/enable projects (like clang/lldb) - even with
the monorepo, I’m still enabling clang/lldb by symlinking them into
llvm/tools, for one specific reason: CMake and relative paths.As long as all the source that is being built is below the toplevel CMake
directory, and the build directory itself is within the toplevel CMake
project directory, CMake uses relative paths in all build files.
(https://github.com/Kitware/CMake/blob/master/Source/cmLocalGenerator.h#L338-L346
contains some mention of this.)This means, my build layout is that I build in llvm-project/llvm/build. In
this setup, CMake produces build files with paths e.g.
…/tools/clang/. If I use LLVM_ENABLE_PROJECTS for enabling clang/lldb,
all clang/lldb source files are referenced by absolute path (instead of
…/…/clang).Using relative paths everywhere has the nice (and for me, at this point,
essential) side effect of making the build output fully independent of the
path to the source tree, allowing ccache to share build artefacts across
two source trees at different locations. This allows builds to run a
couple order of magnitudes faster, if I’ve built the same code version in
a different code tree on the same machine.I guess this could be overcome by adding another top level CMake file at
the top of the monorepo, allowing that to be the main source root of the
build.This seems to be a natural evolution of the monorepo to me to have a top-level CMake instead of pointing at the one nested in the
llvm/directory.
I wasn’t at the round table, was this mentioned?
Yes, briefly, although there are some things we’ll need to fix to make that work. LLVM does some unconventional things in CMake to make the binary directory structure roughly match the install directory structure. Some of those don’t behave well if LLVM isn’t the top-level directory. This is all resolvable by cleaning up usage of various CMake-defined variables.
-Chris