| 20 Feb 2025 |
John Ericson | the symlink hack is only in the source tree | 18:40:03 |
John Ericson | in the installed outputs, everything is normal | 18:40:13 |
John Ericson | and also importantly, were not doing anything like sedding-in the #include "nix/... either, which would screw over meson subproject stuff | 18:40:41 |
emily | alright. well since it doesn't affect any downstream user I guess it doesn't really matter. just seems silly to me | 18:40:47 |
John Ericson | (and I do use that, to work on hydra and nix-eval-jobs and nix all at once, it's nice!) | 18:40:56 |
emily | I think you could construct the symlink hack inside the Meson build rather than polluting the source tree with it. | 18:41:04 |
emily | it supports generated include stuff etc. | 18:41:09 |
John Ericson | that might cause some side effects like more confusing paths in compiler diagnostics | 18:42:15 |
John Ericson | (which is fixable) | 18:42:18 |
John Ericson | * (which is fixable, granted) | 18:42:21 |
John Ericson | if you are willing to try this out, then I would say try either the source symlink or meson-made symlink | 18:42:42 |
John Ericson | (just don't do something where meson configure needs to be re-run every time a header changes, but I don't think you would do anyways :)) | 18:43:13 |
John Ericson | Lix uses include_directories(".." / "..") but that is bad for isolating the headers between projects, and fine-grained per package builds | 18:44:08 |
John Ericson | * Also FWIW: Lix uses include_directories(".." / "..") but that is bad for isolating the headers between projects, and fine-grained per package builds | 18:44:14 |
emily | I'm just going to use the namespace-polluted headers for now; it's not avoidable anyway since the .pc forces them upon you | 18:46:18 |
John Ericson | huh? | 18:46:37 |
John Ericson | for a specific downstream project? | 18:46:47 |
emily | yeah | 18:46:50 |
archercatneo | There's something I was wondering on why it's not done but why couldn't we in step 1 of compilation copy all *.hh files to $dev/include/nix then in the actual compilation do -I $dev/include (and if $dev is not avalible just use the normal meson artifacts dir) | 18:47:02 |
John Ericson | I mean I would not be opposed to backporting the change to get rid of the header polution to 2.26 | 18:47:03 |
emily | as in, <shared.hh> is already taken over anyway, so no point to avoid that by doing <nix/shared.hh> | 18:47:08 |
emily | sure, I think it should be fixed | 18:47:23 |
emily | I don't think I'll be able to allocate time to fixing it myself as I haven't dived into the Nix Meson build and anyway it sounds like there are constraints I don't fully understand preventing what seems like the simple/correct solution to me :) | 18:47:48 |
John Ericson | the simple correct solution being just make an include/nix dir in the source code? | 18:48:18 |
emily | how does this actually work within the Nix build? | 18:48:21 |
emily | how can the libraries see each other's headers? | 18:48:25 |
emily | do they consume the generated .pc files internally? | 18:48:31 |
John Ericson | regular meson deps | 18:48:34 |
John Ericson | no they don't consume the pc files internally sadly | 18:48:46 |
emily | and Meson just adds the entire source tree of every library to the include path of downstream ones? | 18:48:50 |