Otherwise we install a weird `update_core_linalg_named_ops.sh`
maintainer script that refers to the build directory.
There are explicit install targets for some of these and probably
better ways we could install the others, but the Clang derivation
also just explicitly copies a bunch of them, so meh.
Breaks Darwin bootstrap:
CMake Error at /tmp/nix-build-llvm-tblgen-19.1.7.drv-0/llvm-tblgen-src-19.1.7/lldb/test/CMakeLists.txt:197 (message):
LLDB test suite requires libc++, but it is currently disabled. Please add
`libcxx` to `LLVM_ENABLE_RUNTIMES` or disable tests via
`LLDB_INCLUDE_TESTS=OFF`.
It’s probably not too hard to fix but I don’t really understand the
details of this derivation and it’s blocking Darwin `stdenv` builds
with a few days to go until the next cycle, so reverting for now.
This reverts commit d175d8a4c5.
The original tblgen split landed before I was quite ready for it, so
older versions of clang had not been tested.
Reinstate them here.
* Apply patches from LLVM (aside for those from polly, because the
source tree is not present)
* Apply the clang/gnu-install-dirs.patch patch to the clang tree.
* Bracket the build targets with appropriate version checks so we don't
try to build non-existent things.
* Bracket mlir-tblgen with >=16 to mirror the rest of mlir support.
Signed-off-by: Peter Waller <p@pwaller.net>
Background:
LLVM has some tools that run at build time. In native builds, these are
built as a part of the usual build, but in cross builds they need to
come from buildPackages.
In many scenarios this is a small problem because LLVM from
buildPackages is already available as a build; but if cross building a
version of LLVM which is not available (e.g. a new git commit of LLVM)
this results in two builds of LLVM and clang, one native and one for the
cross.
Full builds of LLVM are expensive; and unnecessary in this scenario. We
don't need a native LLVM, only a native copy of the tools which run at
build time. This is only tablegen and related tooling, which are cheap
to build.
Implementation-wise, we introduce a derivation llvmPackages.tblgen,
which specifies the tablegen targets which need to be built and has a
custom installPhase to copy them to the output.
A previous attempt in https://github.com/NixOS/nixpkgs/pull/359967
dropped the use of LLVM_TABLEGEN_EXE and friends on the grounds that
llvm can already cross build these things, but that is false since it's
necessary in that case to wire in a cross compiler. This PR avoids that
problem by allowing access to buildPackages.tblgen.
Signed-off-by: Peter Waller <p@pwaller.net>
