diff options
| author | Peter Waller <p@pwaller.net> | 2024-12-06 11:26:22 +0000 |
|---|---|---|
| committer | Peter Waller <p@pwaller.net> | 2024-12-11 20:55:03 +0000 |
| commit | 59331c3a174455ff68cdaa959dd98a5fd13a6930 (patch) | |
| tree | e55b9a9eda34c8f25aa427adeee0bf840a2601bd /pkgs/development/python-modules/python-mapnik/python-mapnik_std_optional.patch | |
| parent | 4a880d2484c64fb87d8a210c9a7db9b91fa3cad1 (diff) | |
llvmPackages: Split tablegen into its own derivation
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>
Diffstat (limited to 'pkgs/development/python-modules/python-mapnik/python-mapnik_std_optional.patch')
0 files changed, 0 insertions, 0 deletions
