wrapQtAppsHook out of tree?

Help
1

Hi,
trying to build Qt-based Nix-packages unfortunately isn’t really easy, due to the necessary wrappers. The current way seems to be “use wrapQtAppsHook”.

But how can this be done in a standalone package? There, wrapQtAppsHook, qtbase etc. are not found.

Example:

with import <nixpkgs> {};

stdenv.mkDerivation rec {
  pname = "snowman";
  version = "0.1.3";

  src = fetchFromGitHub {
    owner = "yegord";
    repo = "snowman";
    rev = "v${version}";
    sha256 = "1mrmhj2nddi0d47c266vsg5vbapbqbcpj5ld4v1qcwnnk6z2zn0j";
  };

  nativeBuildInputs = [ cmake wrapQtAppsHook ];
  buildInputs = [ makeWrapper boost qt5.full ];

  postUnpack = ''
    export sourceRoot=$sourceRoot/src
  '';
}
1 Like
2 
stdenv.mkDerivation rec {

should be

with libsForQt5;
mkDerivation rec {

In nixpkgs generally we do a:

  pkg = libsForQt5.callPackage ../path/to/file {} ;

the libsForQt5 will bringing that package set and make available a lot of the items you can’t find.

EDIT: more material: Nixpkgs 23.11 manual | Nix & NixOS

3

@jonringer If I’m not mistaken (and I just tested this, so I shouldn’t be), libsForQt5.mkDerivation can’t be referenced like that.

This works though:

let
  pkgs = import <nixpkgs> {};
  mkDerivation = pkgs.libsForQt5.callPackage ({ mkDerivation }: mkDerivation) {};
in mkDerivation rec {
  pname = "snowman";
  version = "0.1.3";

  src = pkgs.fetchFromGitHub {
    owner = "yegord";
    repo = pname;
    rev = "v${version}";
    sha256 = "1mrmhj2nddi0d47c266vsg5vbapbqbcpj5ld4v1qcwnnk6z2zn0j";
  };

  nativeBuildInputs = with pkgs; [ cmake ];
  buildInputs = with pkgs; [ boost ];

  postUnpack = ''
    export sourceRoot=$sourceRoot/src
  '';
}
4

It probably is the case, I’ve never tried to do a qt5 app outside of nixpkgs

5

Ok, I’ve tested it with the following and it worked:

with import <nixpkgs> {};

pkgs.libsForQt5.callPackage({mkDerivation}: mkDerivation) {} rec {
  pname = "snowman";
  version = "0.1.3";
  ...

Is there any good documentation for this?
From the current nixpkgs-manual, I could not have guessed this.

1 Like
6

hmm, that’s one way to do it so the package scope aligns. But you’re correct, my original proposal doesn’t work. I’m not super sure how the Qt injection does everything. cc @worldofpeace @jtojnar

7

mkDerivation is in qt5 attribute set, not libsForQt5. Though adding wrapQtAppsHook to nativeBuildInputs should work with stdenv.mkDerivation (see Qt: Do not require mkDerivation by ttuegel · Pull Request #71089 · NixOS/nixpkgs · GitHub).

And we can add this use case to the lists of reasons I do not like libsForQt5.callPackage.

8

I think there would have been a lot less pain if the build helper was named buildQt5Application instead of shadowing the mkDerviation function. This would also make the libsForQt5.callPackage less conflicting with what’s in scope.

1 Like
9

Maybe it will in the future; but at the moment, wrapQtAppsHook cannot be found in stdenv.mkDerivation.
(error: undefined variable 'wrapQtAppsHook' at /path/to/default.nix)

10

wrapQtAppsHook is also in qt5 attribute set.

Also note that function calls like stdenv.mkDerivation have no effect on scope – only function declaration, let binding, recursive set, and with statement can affect scope.

1 Like