| 20 Feb 2025 |
 John Ericson | src/lib<blah>/nix -> .. symlink | 18:37:30 |
| John Ericson | and then make all our headers do #include "nix/*" | 18:37:53 |
| John Ericson | and make the PC files not have the /nix | 18:38:14 |
| John Ericson | that solution avoids moving source files around, which will make Eelco happy. (More seriously, it will keep the headers next to their corresponding sources, which he said he likes) | 18:38:44 |
 emily | why can't you just do #include <nix/…> in the headers, have src/lib<blah>/include/nix be where the headers are, and add the built lib<blah>s as normal Meson dependencies? | 18:39:02 |
| emily | I don't think you need any symlink hacks to make that work | 18:39:07 |
| John Ericson | you need the symlink hack if you want foo.hh next to foo.cc | 18:39:23 |
| John Ericson | I am happy to have that conversation with the rest of the team, but I don't think we should be blocked on that | 18:39:53 |
| 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 |
