Nix/non-FHS Linux support: build.zig GCC include path discovery rejects paths outside /usr/

[haze]

I'm trying to use libqt6zig on NixOS (and with Nix devShell environments on non-NixOS). Currently it doesn't work out of the box because of two issues in build.zig:

1. GCC include path filter is too restrictive (line 42)

The GCC C++ header discovery runs gcc -xc++ -E -Wp,-v /dev/null and filters the output with:

if (std.mem.startsWith(u8, line, " /usr/")) {

On Nix, all paths are under /nix/store/, so nothing passes this filter. The -nostdinc++ / -nostdlib++ flags strip the default C++ headers (correctly, since Qt needs libstdc++ not libc++), but then the GCC-discovered paths that would re-add them are all rejected.

The fix is to accept any indented absolute path, which is all the filter was really doing — distinguishing actual paths from noise lines in GCC's stderr:

const trimmed = std.mem.trimLeft(u8, line, " ");
if (trimmed.len > 0 and trimmed[0] == '/' and line.len > trimmed.len) {

This preserves the existing behavior on FHS distros (all /usr/ paths still match) while also working on Nix, Guix, and any other non-FHS layout.

2. os_include_path is hardcoded to FHS paths only

The comptime os_include_path array only lists paths like /usr/include/qt6, /usr/include/KF6, etc. On Nix these don't exist, Qt/KDE headers are in scattered /nix/store/ paths.

Nix's mkShell provides all include paths via the NIX_CFLAGS_COMPILE environment variable as -isystem entries (this is the same mechanism Zig's own std.zig.system.NativePaths uses internally). Parsing this env var at build time and adding the discovered paths to qt_include_path makes the hardcoded os_include_path unnecessary on Nix, while leaving it as a working fallback on FHS systems.

I have a working patch against the current build.zig that I can submit as a PR if you're open to it. With the patch, libqt6zig works on Nix with a plain mkShell that just lists Qt/KDE packages in buildInputs — no workarounds needed.

[rcalixte]

Hi! Thanks for the interest!

It's perhaps important to establish some precedent here to start.

1. GCC include path filter is too restrictive (line 42)

This requires some longer reflection. I definitely won't be making this change in the short-term and there's arguably a simpler approach that could be less brittle in the long-term than the proposal or the current implementations. The benefit of the current implementation being that it is known to work across all supported platforms with the bonus that the sibling project has a similar functional implementation.

2. os_include_path is hardcoded to FHS paths only

I can be more certain that this is highly unlikely to ever reside upstream. While incidental support for an unsupported platform can be a satisfactory happenstance, muddying the lines of what is and is not supported is unacceptable.

In all, you should feel empowered to maintain a personal fork for your uses. Incidentally, there is additional platform support upcoming but other than specifically that, future changes required for newer stable versions of Zig, and future support for additional Qt ecosystem modules to the library, the build system is hopefully stabilized in its mostly functional state.

Thanks again!

[rcalixte]

Hi @haze, regarding the first topic here, I've relaxed the pattern matching in the build system's logic and added some logic for path validation. In the short-term, I believe this should address your issues while simultaneously not destabilizing the supported platforms. The library's existing option for extra paths (-Dextra-paths in the README) should also provide scaffolding you can use to provide the additional include paths in your environment.

With both of these in place, I believe you should be able to consume the library without having to maintain a fork if you find that to be optimal. The same caveats about being on an unsupported platform still apply.

Thanks!