GLib setup hook expects GSettings schemas to be installed in ${!outputLib}
and tries to move them to gsettings-schemas/$name subdirectory to prevent
conflicts. But the schemas will only end up in the library output when
the build system recognizes makeFlags set by the setup hook, and in that case
the move is not necessary, since the flag already includes the subdirectory.
Normally, this is not an issue, since most packages relying on GSettings
schemas either still use Autotools with gsettings.m4, or do not have a lib
output set. But with the promulgation of multiple outputs in Nixpkgs and
more and more projects switching to Meson, the issue will become increasingly
common.
We first noticed this problem with nm-applet.
Closes https://github.com/NixOS/nixpkgs/issues/45043
* openblas: simplify a bit, fix doCheck so tests are enabled non-cross.
* doCheck should be 'true' in (at least) the non-cross case,
this looks like an inverted check that's largely benign
* doCheck will be set to 'false' in the cross case anyway,
makeDerivation does this IIRC
* targetPrefix can be used without checking, probably by design
Derivation hash does change but no "real" functionality change intended.
* openblas: nix types for config attrs (hash-preserving)
* openblas: more nix-ification, merge in cross attrs, prefer to always set
(but set appropriately for cross and non-cross cases both)
* I'm not sure what NO_BINARY_MODE does,
this change now sets explicitly false in the non-cross scenario
(previously unset unless cross).
* Drop musl NO_AFFINITY case, will be removed in upgrade shortly
* openblas: 0.3.4 -> 0.3.5
* Drop patches, now included!
* Fixes system tray icon madness w/awesomeWM (and others?),
oh joyous day what a time to be alive :)
(parent_relative fixups, been using for a while, woohoo!)
This package contains several CMake files used for setting up its
provided tools for use in other projects build with CMake.
While packaging *ktouch* I found out that the ${_qt5Core_install_prefix}
variable doesn't expand at all, rendering the path to the `qmlcachegen`
binary useless. As a fix, the command itself is used instead of the path
to the binary.
Before this commit it built fine a few times for me,
i.e. without the single test, but it failed on Hydra anyway.
I guess jtojnar also tested the final expression with all tests,
so apparently they are sensitive the the kind of machine they run on.
