e0464e4788
In preparation for the deprecation of `stdenv.isX`. These shorthands are not conducive to cross-compilation because they hide the platforms. Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way One example of why this is bad and especially affects compiler packages https://www.github.com/NixOS/nixpkgs/pull/343059 There are too many files to go through manually but a treewide should get users thinking when they see a `hostPlatform.isX` in a place where it doesn't make sense. ``` fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is" fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is" fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is" fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is" fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is" fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is" fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is" fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is" fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is" ``` |
||
|---|---|---|
| .. | ||
| patches | ||
| 1.6-bin.nix | ||
| default.nix | ||
| generic-bin.nix | ||
| generic.nix | ||
| README.md | ||
Julia
Julia, as a full-fledged programming language with an extensive standard library that covers numerical computing, can be somewhat challenging to package. This file aims to provide pointers which could not easily be included as comments in the expressions themselves.
For Nixpkgs, the manual is as always your primary reference, and for the Julia side of things you probably want to familiarise yourself with the README , build instructions, and release process. Remember that these can change between Julia releases, especially if the LTS and release branches have deviated greatly. A lot of the build process is underdocumented and thus there is no substitute for digging into the code that controls the build process. You are very likely to need to use the test suite to locate and address issues and in the end passing it, while only disabling a minimal set of broken or incompatible tests you think you have a good reason to disable, is your best bet at arriving at a solid derivation.