In reply to @Ericson2314:matrix.org
emily: that's because -I.../nix in the pkg-config`

Robert Hensing (roberth): John Ericson: after further experimentation I continue to believe that the Nix 2.26 componentized build is broken as a library:

yuyuko:/v/f/y/m/T/tmp.IYaTKFuZIs
❭ mkdir -p {a,b}/nix

yuyuko:/v/f/y/m/T/tmp.IYaTKFuZIs
❭ echo '#include "y.h"' >a/nix/x.h

yuyuko:/v/f/y/m/T/tmp.IYaTKFuZIs
❭ echo '#error worked' >b/nix/y.h

yuyuko:/v/f/y/m/T/tmp.IYaTKFuZIs
❭ echo '#include <nix/x.h>' >test.c

yuyuko:/v/f/y/m/T/tmp.IYaTKFuZIs
❭ clang -Ia -Ib test.c
In file included from test.c:1:
a/nix/x.h:1:10: fatal error: 'y.h' file not found
    1 | #include "y.h"
      |          ^~~~~
1 error generated.

nix/shared.hh in nix-main has #include "path.hh", which is nix/path.hh in nix-store. I'm using inputs.nix.packages.${final.stdenv.hostPlatform.system}.default direct from the flake so there's nothing from the Nixpkgs packaging or the split library packages interfering here.

the .pc files specify -I…/nix as a compiler flag directly, which does make it work:

yuyuko:/v/f/y/m/T/tmp.IYaTKFuZIs
❭ echo '#include "x.h"' >test.c

yuyuko:/v/f/y/m/T/tmp.IYaTKFuZIs
❭ clang -Ia/nix -Ib/nix test.c
In file included from test.c:1:
In file included from a/nix/x.h:1:
b/nix/y.h:1:2: error: worked
    1 | #error worked
      |  ^
1 error generated.

but this implies that (a) all code that previously used #include <nix/foo.hh> is broken, and (b) you can't use Nix as a library without it polluting your include namespace with names as generic as "hash.hh", "path.hh", and "shared.hh". AFAICT Hydra just lives with that. that seems like it's both bad and a substantial regression? I think that the -I…/nix thing should not be part of the upstream .pc files but in any case I don't think the headers should depend on that out-of-band configuration to have correct interdependent #includes at all