The default installation path for QPA plugins is appended to
QT_QPA_PLATFORM_PLUGIN_PATH, making it unnecessary to wrap some applications and
preventing applications from loading platform plugins from the wrong Qt version.
`stack setup` should not be called inside `nix-build` because
that makes stack download a GHC instead of using nix's one
(the one provided `generic-stack-builder.nix` as the `ghc` argument),
which will not work.
Further evidence for this is that the `stack --nix` support
intentionally uses `--system-ghc` for the same purpose.
In configured builds other tools tries to call meson by directly
passing meson tools directly to python. Since they were shell scripts
due wrapping this failed
See previous commit for what was done to `binutils` to make this
possible.
There were some uses of `forcedNativePackages` added. The
combination of overrides with that attribute is highly spooky: it's
often important that if an overridden package comes from it, the
replaced arguments for that package come from it. Long term this
package set and all the spookiness should be gone and irrelevant:
"Move along, nothing to see here!"
No hashes should be changed with this commit
We want code such as `(pkg.override {}).overrideScope (self: super: {})` to
work. This didn't work before, since `override` will call the original package
again, and the attribute `overideScope`, which `callPackageWithScope` added,
wasn't added again. The fix for this is to modify the package function itself
to include the `callPackageWithScope` attribute, so it'll be re-added whenever
the function is overriden for with arguments.
There is a small problem here though: since callPackage uses some magic
(`builtins.functionArgs`) to determine the auto-arguments of a function, we
can't just write `callPackageWith scope drvScope`, since
`builtins.functionArgs drvScope` will be `{}`. To fix this, we implement our own
`callPackageWith`.
Fixes https://github.com/NixOS/nixpkgs/issues/7953.
Closes https://github.com/NixOS/nixpkgs/pull/9336.
(this is reapplying 6b1957d17a, which got
lost in a merge)
Including apple_sdk.sdk is generally a recipe for a bad time on LLVM 3.8
and above, since you end up with bad headers in the wrong place that hurt
the new libc++ in 3.8 and above. In this case, qt only wanted the super-
generic SDK for CUPS headers, which we can just depend on directly now.
stdenv.cross is a silly attribute that needs to go leaving the well-defined hostPlatform and targetPlatform. This PR doesn't remove it, but changes its definition: before it tracked the target platform which is sometimes more useful for compilers, and now it tracks the host platform which is more useful for everything else. Most usages are libraries, falling in the "everything else" category, so changing the definition makes sense to appease the majority. The few compiler (gcc in particular) uses that exist I remove to use targetPlatform --- preserving correctness and becoming more explicit in the process.
I would also update the documentation aside mentioning stdenv.cross as deprecated, but the definition given actually erroneously assumes this PR is already merged!
The previous commit redefines `stdenv.cross` for the sake of normal
libaries, the most common use-case of that attribute. Some compilers
however relied on the old definition so we have them use
`targetPlatform` instead. This special casing is fine because we
eventually want to remove `stdenv.cross` and use either `hostPlatform`
or `targetPlatform` instead.
This reverts commit 9f86136cef.
Rust is nowadays required for building Firefox, so the channel updates
are blocked on this.
(It also builds fine for me.)
