For reference I also tried with libsForQt5.callPackage and then wrapQtAppsHook as an input parameter (so it would work also in the sandbox case).

However I get:

dyld: Library not loaded: /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
  Referenced from: /nix/store/xkxq0dd7kfagz04gwbmvgjjbvf33bl4s-qtbase-5.12.7-dev/bin/qmake
  Reason: no suitable image found.  Did find:
        /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation: file system sandbox blocked stat()
        /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation: file system sandbox blocked stat()
./configure: line 26: 17806 Abort trap: 6           ${QMAKE} "${DIR}"

if anyone can shed some light I am more than happy to do it the "proper way".

For reference I also tried with libsForQt5.callPackage and then wrapQtAppsHook as an input parameter (so it would work also in the sandbox case).

Those have nothing to do with sandboxing. As far as I understand, you should be able to switch to libsForQt5.callPackage without even a rebuild.

Those have nothing to do with sandboxing. As far as I understand, you should be able to switch to libsForQt5.callPackage without even a rebuild.

Sandboxing was meant in the context that on Darwin I just use wrapQtApp without ever declaring where that comes from. If the build was done in a sandbox it would fail.

My understanding was that with
nativeBuildInputs = [ wrapQtAppsHook ];

this would become a proper build input but of course I might be totally wrong here. BTW, found a similar issue just regarding Emacs (#47413). I have the store on MacOS on a dedicated volume called /nix - if that causes the problems. That is some security sandbox, but I don't understand yet how to solve this (using my method the built application works perfectly).

Ah silly me. It was caused since I experimented with sandbox = true in /etc/nix/nix.conf

Sandboxing was meant in the context that on Darwin I just use wrapQtApp without ever declaring where that comes from. If the build was done in a sandbox it would fail.

The call to "wrapQtApp" from a shell script is resolved using the "PATH" environment variable, which is initialized by the stdenv and should not contain any impure paths unless it's somehow modified.

My understanding was that with
nativeBuildInputs = [ wrapQtAppsHook ];

this would become a proper build input but of course I might be totally wrong here.

If I'm not mistaken, mkDerivation provided by the libsForQt5.callPackage may implicitly include wrapQtAppsHook to nativeBuildInputs for you.

BTW, found a similar issue just regarding Emacs (#47413). I have the store on MacOS on a dedicated volume called /nix - if that causes the problems. That is some security sandbox, but I don't understand yet how to solve this (using my method the built application works perfectly).

Sandboxing on darwin is currently not properly supported by nixpkgs for the impure Apple frameworks (#67166 mentions a workaround).

@GrahamcOfBorg build sleepyhead