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"
```
* doc: add stdenv passthru chapter
Broad strokes:
- create the chapter
- move existing stdenv passthru coverage into it
- move out-of-place coverage of passthru.tests from the stdenv meta chapter into it
- (try to) apply 1-sentence-per-line to text I've touched
- add legacy anchors for everything moved
- update existing links to the new anchors
- add tentative motivating text
- make nixpkgs-internal links relative/branchless
razor: if it is only ever needed by contributors, which is likely if links
refer to the latest revision of the source code, then it's for
the contributor guide
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Fixes#298285, alternative to #300386.
As suggested in #298285 `lib64` was renamed to `lib`, so just doing the same
as for `lib64` seems to fix the issue.
See also recent discussion in #300386.
Use of binaries from NDK `toolchains` has been broken by following PR:
* https://github.com/NixOS/nixpkgs/pull/195752
I'm splitting the patchInstructions to run the ELF patching only on Linux.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
- Replace cmdline-tools with tools because tools is obsolete now.
- Depend emulator package to systemImages
androidenv: fix issues on the PR
androidenv: reformat
androidenv: support excluding of `tools` package
androidenv: provide `tools`, and `build-tools`, dependencies
androidenv: replace includeTools with toolsVersion
androidenv: fix a typo
androidenv: add tests to check licenses and installed packages
androidenv: check if tests are running! this commit should fail!
androidenv: fix problems in the review https://github.com/NixOS/nixpkgs/pull/208793
androidenv: add test-suite to handle more tests around
androidenv: fix the test after couldn't running them with ofborg
Update pkgs/development/mobile/androidenv/build-tools.nix
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
androidenv: Resolving https://github.com/NixOS/nixpkgs/pull/208793#discussion_r1065851539
Update pkgs/development/mobile/androidenv/cmdline-tools.nix
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Update pkgs/development/mobile/androidenv/tools.nix
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
androidenv: fix a typo
infinite recursion was due to autoPatchelfHook being in buildInputs of
platform-tools, i will add a lint for it in nix-community/nixpkgs-lint.
```
$ nix build ".#pkgsCross.aarch64-android-prebuilt.hello" --show-trace 2>&1 | rg 'while evaluating the attr.+deriv'
… while evaluating the attribute 'stdenv' of the derivation 'zlib-aarch64-unknown-linux-android-1.2.13'
… while evaluating the attribute 'CPPFLAGS' of the derivation 'python3-aarch64-unknown-linux-android-3.10.8'
… while evaluating the attribute 'setuptools' of the derivation 'python-catch-conflicts-hook'
… while evaluating the attribute 'nativeBuildInputs' of the derivation 'python3.10-pyelftools-0.28'
… while evaluating the attribute 'passAsFile' of the derivation 'python3-3.10.8-env'
… while evaluating the attribute 'pythonInterpreter' of the derivation 'auto-patchelf-hook'
… while evaluating the attribute 'buildInputs' of the derivation 'platform-tools-33.0.2'
… while evaluating the attribute 'installPhase' of the derivation 'ndk-24.0.8215888'
… while evaluating the attribute 'installPhase' of the derivation 'aarch64-unknown-linux-android-ndk-toolchain-24.0.8215888'
… while evaluating the attribute 'bintools_bin' of the derivation 'aarch64-unknown-linux-android-ndk-toolchain-wrapper-24.0.8215888'
… while evaluating the attribute 'bintools' of the derivation 'aarch64-unknown-linux-android-ndk-toolchain-wrapper-24.0.8215888'
… while evaluating the attribute 'defaultNativeBuildInputs' of the derivation 'stdenv-linux'
… while evaluating the attribute 'stdenv' of the derivation 'hello-aarch64-unknown-linux-android-2.12.1'
```
stdenv -> stdenv.cc -> bintools -> android-ndk-toolchain -> ndk -> platform-tools -> auto-patchelf-hook -> python3 -> zlib -> stdenv -> stdenv.cc -> ...
autoPatchelfHook was in buildInputs of platform-tools so we needed the host tools to build
it but platform-tools was a required tool
