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.
The `platform` field is pointless nesting: it's just stuff that happens
to be defined together, and that should be an implementation detail.
This instead makes `linux-kernel` and `gcc` top level fields in platform
configs. They join `rustc` there [all are optional], which was put there
and not in `platform` in anticipation of a change like this.
`linux-kernel.arch` in particular also becomes `linuxArch`, to match the
other `*Arch`es.
The next step after is this to combine the *specific* machines from
`lib.systems.platforms` with `lib.systems.examples`, keeping just the
"multiplatform" ones for defaulting.
Don't use ./shared.nix as it's not shared anymore.
Fix tests with an upstream patch and a few commands in postPatch.
Assert that blas and lapack are compatible.
Rename utf8proc patch.
This is a better name since we have multiple 64-bit things that could
be referred to.
LP64 : integer=32, long=64, pointer=64
ILP64 : integer=64, long=64, pointer=64
This makes packages use lapack and blas, which can wrap different
BLAS/LAPACK implementations.
treewide: cleanup from blas/lapack changes
A few issues in the original treewide:
- can’t assume blas64 is a bool
- unused commented code
There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
