Change:
./qtbase.patch.d/0010-qtbase-qtpluginpath.patch ./qtbase.patch.d/0011-qtbase-assert.patch ./qtbase.patch.d/0012-fix-header_module.patch <ins> # Ensure -I${includedir} is added to Cflags in pkg-config files. # See https://github.com/NixOS/nixpkgs/issues/52457 ./qtbase.patch.d/0014-qtbase-pkg-config.patch </ins> # https://bugreports.qt.io/browse/QTBUG-81715 # remove after updating to qt > 5.12.7 (fetchpatch {

Discussion:
The pkg-config Cflags for qtdeclarative is missing . It only has . It appears that conventionally both of these paths appear in the include path, so that people write code like: where they can choose to put the "package" name in the include path. qtbase already allows for this. The same problem may apply to all the other qt packages. Note the Cflags in both files below: system: host os: multi-user?: sandbox: version: channels(lukeworth): nixpkgs:
I ran into this problem as well while moc-ing. Note that the Qt Headers themselves mainly use the include form so Qt itself expects the include path . Is this an upstream issue?
Yeah, this looks like boog – has in the .pc files and it does not look like they do anything special.
Looking at , the key is present even in 5.12.4 so we must be breaking it somewhere.
also adds (using Qt-base as an example here).
Likely caused by this line:
Do you think we can build Qt differently so that the .pc-files are generated correctly? It's not clear to me how the files are created.
So when the , Qt marks it as a system include path: and qmake’s pkg-config generator considers it unnecessary to add to the file since it will be available anyway: And it is in fact right, the cc-wrapper will add so C/C++ compilers should have no problem finding the headers.
Confirmed using the patch below that cc-wrapper only includes the dependency include paths, not qtsvg’s own include path so I am still not sure how it gets into .
There are two things I do not understand: does the get into the variable when building ? (Assuming, I diagnosed the correct , maybe try patching the line to run unconditionally to verify.) causes a problem for you. The cc-wrapper make sure the is visible to the compiler, even when is omitted from the file (or there is no file at all). Does MOC use something else than the compiler from ? What is the error message? I am not familiar with Qt at all so for further debugging, someone like will be needed.
The moc-compiler has its own parser et.c. so is completely independent from $CXX AFAIK. What we do is to pass all include flags explicitly, as found using pkg-config.

Which works on CentOS but not in Nix. Actually, this applies in general for us as our internal packages are quite big, so we want to cherry-pick from buildInputs using things like pkg-config only the necessary bits for each library. I haven't managed (yet) to provide an unwrapped gcc with a standard environment, but that's the goal.
Actually, this seems to work (at least in terms of adding the missing include path, I haven't tested it more):
As , this is caused by the lack of a unified system include path in Nixpkgs. We could try to patch that statement so that is unconditionally; I doubt it would hurt anything.
I'll update to patch instead, ok?
Sounds great, thanks!
I marked this as stale due to inactivity. &rarr;
Did you ever try the fix from ?
Thanks for following up on this :) Unfortunately (fortunately?) I no longer work on Qt applications so I haven't needed to address this.
this was likely fixed in , unless you disagree I think you can close this ticket.
Thanks