Manipulating the store paths on the Nix side doesn’t work with CA
derivations (because these paths are just placeholders of the form
`/{hash}` at eval-time)
Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb3, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
Provides a few hopefully helpful pointers that would not work well as
inline comments in the expressions themselves. Most likely the README
will need to be expanded upon over time to cover how we handle the Julia
release process, but I hope this is a good starting point.
Provides very little comfort compared what is outlined in the
manual [1], only supports a single version, and would probably be better
to implement as a general Nixpkg tool.
[1]: https://nixos.org/manual/nixpkgs/stable/#sec-source-hashes
As far as I can tell this patch is redundant as all pre-compiled code
generated at build time is baked into the Julia system image and will
thus never get invalidated: Note that for both julia_10 and julia_15
there are no `.ji` files produced in the derivations.
buildPackages.stdenv.cc.cc is a C compiler that runs on the build
platform and produces binaries for the host platform. This is not
what we want. Also pkgsHostTarget.stdenv.cc is not the compiler we
want as stdenv always runs on the previous stage so to say (the stdenv
is used to build the package set, in the case of cross compiling
this is not done natively). Thus pkgsHostTarget.targetPackages.stdenv.cc
is what we want.
This might be a bit debatable but upstream uses "xx" instead of "++"
when using it as identifier / in the code (file/directory names, build
scripts, website URLs, etc.) so we should probably too.
And at least the attribute name and pname will be consistent now.
mrustc is mostly patched to use shared LLVM sources but still uses
in-tree source for compiler-rt from LLVM 7. This needs to be patched to
compile under glibc 2.31 or later. It's easy enough to reapply all our
compiler-rt patches here.
