| 20 Feb 2025 |
 emily | which does not seem like it would require any strange low-level workarounds for the output selection machinery, because they would just be real outputs (that happen to be full of symlinks) | 00:20:26 |
 roberth | I do have a goal for that machinery to not be strange, because it helps remove certain dependency chains, especially those in foo.doc outputs, but that is secondary | 00:21:56 |
| roberth | can be used to simplify bootstrapping a bit | 00:22:34 |
| emily | ok, a bigger issue is that e.g. /nix/store/8fc4pxbkadmhnw2zspsbiayz0qdkkm94-nix-main-2.26.1-dev/include/nix/shared.hh does #include "path.hh", but <nix/path.hh> is in nix-store, and AFAICT even if you have them both on the include path a relative include won't look at "the same prefix in another directory" like that | 00:22:44 |
| emily | (I haven't tested with your PR yet since it requires a full Nix rebuild, I'm just manually adding libs.foos, but it seems like the separate library packages just don't work so I don't think propagation would fix that) | 00:23:04 |
| emily | (a symlink farm would hide the issue I think, by making path.hh be in the same directory as shared.hh, but it seems like a general issue for having split-up components) | 00:23:24 |
| emily | hm, it might be user error actually. let me test some more | 00:24:30 |
| roberth | between these packages, meson seems to figure things out, fwiw | 00:25:26 |
| roberth | we could make dev a symlink farm if we need to | 00:25:58 |
 John Ericson | emily: you might want to see what nix-eval-jobs and hydra are now doing for 2.26 | 00:29:11 |
| John Ericson | yes the config stuff is not yet good by any means | 00:29:24 |
| emily | looks like explicit -includes rather than anything in the .pc? https://github.com/NixOS/hydra/blob/18c0d762109549351ecf622cde34514351a72492/meson.build#L22-L26 | 00:30:17 |
| John Ericson | yes :* | 00:30:27 |
| John Ericson | * yes :( | 00:30:30 |
| John Ericson | now that we are more explicit about the configuration variables than with autoconf, I want to only export the ones the headers actualy depend on | 00:31:15 |
| John Ericson | (which should be a lot less) | 00:31:21 |
| John Ericson | and use regular #include | 00:31:37 |
| John Ericson | emily: another thing is I don't know whether #include "foo" or #include <nix/foo> is better within nix itself | 00:34:26 |
| John Ericson | the latter violates "don't know your own name" but keeps us dogfooding our headers as others would use them | 00:34:50 |
| John Ericson | (the /nix in the pkg-config is definitely bad) | 00:35:04 |
| John Ericson | * (the /nix in the *.pc is definitely bad) | 00:35:14 |
| emily | 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 |
| emily | but if it does then I guess it's fine | 00:36:48 |
| John Ericson | I am not sure that works | 00:43:18 |
| John Ericson | there is just the sibling even if not in same path rule | 00:43:34 |
| John Ericson | * there is just the sibling even if on directly on the path rule | 00:43:44 |
| emily | then I'm not sure how ^ ever works | 00:47:10 |
| John Ericson | emily: that's because -I.../nix in the pkg-config` | 01:38:14 |
| John Ericson | and also the meson build time C flags | 01:38:24 |
| John Ericson | * and also the meson when building Nix itself C flags | 01:38:37 |
