First of all, LLVM_TOOLS_INSTALL_DIR put there breaks our NixOS
builds, because LLVM_TOOLS_INSTALL_DIR defined the same as
CMAKE_INSTALL_BINDIR becomes an *absolute* path, and then when
downstream projects try to install there too this breaks because our
builds always install to fresh directories for isolation's sake.
Second of all, note that LLVM_TOOLS_INSTALL_DIR stands out against the
other specially crafted LLVM_CONFIG_* variables substituted in
llvm/cmake/modules/LLVMConfig.cmake.in.
@beanz added it in d0e1c2a550ef348aae036d0fe78cab6f038c420c to fix a
dangling reference in AddLLVM, but I am suspicious of how this
variable doesn't follow the pattern.
Those other ones are carefully made to be build-time vs install-time
variables depending on which LLVMConfig.cmake is being generated, are
carefully made relative as appropriate, etc. etc. For my NixOS use-case
they are also fine because they are never used as downstream install
variables, only for reading not writing.
To avoid the problems I face, and restore symmetry, I deleted the
exported and arranged to have many ${project}_TOOLS_INSTALL_DIRs.
AddLLVM now instead expects each project to define its own, and they
do so based on CMAKE_INSTALL_BINDIR. LLVMConfig still exports
LLVM_TOOLS_BINARY_DIR which is the location for the tools defined in
the usual way, matching the other remaining exported variables.
For the AddLLVM changes, I tried to copy the existing pattern of
internal vs non-internal or for LLVM vs for downstream function/macro
names, but it would good to confirm I did that correctly.
Instead of each project having to define a different macro for this, why not just do this based on the current project in scope?
I think this would be a less invasive change.
FWIW my review can only help in these small matters of coding, I can't really review this from the perspective of the intended effect, I am just a clang developer and I never have to package or install LLVM I built myself, I just test stuff from the build dir :)