!VRULIdgoKmKPzJZzjj:nixos.org

Nix Hackers

918 Members
For people hacking on the Nix package manager itself191 Servers

Load older messages


SenderMessageTime
20 Feb 2025
@Ericson2314:matrix.orgJohn Ericson * yes :(00:30:30
@Ericson2314:matrix.orgJohn Ericsonnow that we are more explicit about the configuration variables than with autoconf, I want to only export the ones the headers actualy depend on00:31:15
@Ericson2314:matrix.orgJohn Ericson(which should be a lot less)00:31:21
@Ericson2314:matrix.orgJohn Ericson and use regular #include 00:31:37
@Ericson2314:matrix.orgJohn Ericson emily: another thing is I don't know whether #include "foo" or #include <nix/foo> is better within nix itself 00:34:26
@Ericson2314:matrix.orgJohn Ericsonthe latter violates "don't know your own name" but keeps us dogfooding our headers as others would use them00:34:50
@Ericson2314:matrix.orgJohn Ericson (the /nix in the pkg-config is definitely bad) 00:35:04
@Ericson2314:matrix.orgJohn Ericson * (the /nix in the *.pc is definitely bad) 00:35:14
@emilazy:matrix.orgemily I'm honestly surprised if #include "b.h" works to find y/include/foo/b.h from x/include/foo/a.h even if both are on the include path 00:36:45
@emilazy:matrix.orgemilybut if it does then I guess it's fine00:36:48
@Ericson2314:matrix.orgJohn EricsonI am not sure that works00:43:18
@Ericson2314:matrix.orgJohn Ericsonthere is just the sibling even if not in same path rule00:43:34
@Ericson2314:matrix.orgJohn Ericson * there is just the sibling even if on directly on the path rule00:43:44
@emilazy:matrix.orgemilythen I'm not sure how ^ ever works00:47:10
@Ericson2314:matrix.orgJohn Ericson emily: that's because -I.../nix in the pkg-config` 01:38:14
@Ericson2314:matrix.orgJohn Ericsonand also the meson build time C flags01:38:24
@Ericson2314:matrix.orgJohn Ericson * and also the meson when building Nix itself C flags01:38:37
@joerg:thalheim.ioMic92
In reply to @Ericson2314:matrix.org
emily: that's because -I.../nix in the pkg-config`
Could we not extend cflags in our pc files to include those conf headers?
02:39:13
@joerg:thalheim.ioMic92Than other projects don't need to do the same02:39:54
@joerg:thalheim.ioMic92* Than other projects don't need anything except for using pc files02:41:00
@joerg:thalheim.ioMic92I remember having subtle runtime crashes rather than build errors when I did forget one of the includes02:42:01
@flokli:matrix.orgflokliLovely03:23:19
@Ericson2314:matrix.orgJohn Ericson Mic92: yeah we can do that 03:28:00
@Ericson2314:matrix.orgJohn Ericsonthat is definitely better than the status quo03:28:06
@Ericson2314:matrix.orgJohn Ericsoneven if it is less than the ideal thing03:28:14
@Ericson2314:matrix.orgJohn Ericson Eelco: Can you review https://github.com/NixOS/nix/pull/12531 ? 18:30:20
@Ericson2314:matrix.orgJohn EricsonThe most interesting part is IMO the symlink resolution bits18:31:57
@emilazy:matrix.orgemily

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

18:36:06
@Ericson2314:matrix.orgJohn Ericson emily: I agree that nix/ should work downstream 18:37:07
@Ericson2314:matrix.orgJohn Ericsonhere is what I am thinking we should do18:37:14

Show newer messages


Back to Room ListRoom Version: 6