| 17 Oct 2024 |
 Alyssa Ross | Okay | 10:53:58 |
| Alyssa Ross | So let's put the hack back? | 10:54:02 |
 emily | yeah it seems like the way forward. K900 implied we could have a better version of the hack? | 10:54:29 |
 K900 | Yes, we just need to symlink out instead of in | 10:54:42 |
| emily | FWIW it's possible that maybe getting pkgconf to eat absolute paths is untenable or there's some other issue with doing it that means we have to propagate anyway | 10:54:57 |
| emily | but I'd at least like to investigate the possibility | 10:55:02 |
| emily | since making it more like how linking works for us in general seems like a good thing | 10:55:08 |
| emily | rather than shoving .pc stuff into the kind of global shared namespace we try to avoid | 10:55:21 |
| K900 | As in, instead of
$out/include/pixman-1 -> $out/include
$out/include/pixman.h
we do
$out/include/pixman-1/pixman.h
$out/include/pixman.h -> $out/include/pixman-1/pixman.h
| 10:55:26 |
| emily | it's Requires.private, after all | 10:55:34 |
| emily | In reply to @k900:0upti.me
As in, instead of
$out/include/pixman-1 -> $out/include
$out/include/pixman.h
we do
$out/include/pixman-1/pixman.h
$out/include/pixman.h -> $out/include/pixman-1/pixman.h
sgtm | 10:55:58 |
| Alyssa Ross | So technically, we could just embed the absolute pkg-config paths as comments in the .pc file, right? :P | 11:01:57 |
| Alyssa Ross | The references would be created, and pkg-config/pkgconf wouldn't have to be modified. | 11:02:10 |
| emily | how would they get into the path that pkgconf searches? | 11:03:05 |
| emily | they'd get into the sandbox but pkgconf has no reason to dig into random /nix/store directories right? | 11:03:19 |
| Alyssa Ross | we already have a working PKG_CONFIG_PATH
| 11:03:37 |
| emily | I was looking at the code just now and I think it'd be relatively simple to just make it interpret absolute paths without search; or maybe each .pc could set its own private search path | 11:03:40 |
| emily | In reply to @qyliss:fairydust.space
we already have a working PKG_CONFIG_PATH
yeah but only for things that are actually build inputs right…? | 11:03:47 |
| Alyssa Ross | ohh | 11:03:53 |
| emily | which they deliberately wouldn't be in this case | 11:03:54 |
| Alyssa Ross | I guess yeah | 11:03:57 |
| emily | In reply to @emilazy:matrix.org
I was looking at the code just now and I think it'd be relatively simple to just make it interpret absolute paths without search; or maybe each .pc could set its own private search path we could do whichever of these is easier to implement, coordinate with upstream, and change how we patch .pc files for whatever is decided if necessary | 11:04:17 |
| emily | but I don't see any obvious blockers other than me having to patch an unfamiliar C code base and add more crap to the fixup phase | 11:04:41 |
| emily | In reply to @emilazy:matrix.org
yeah but only for things that are actually build inputs right…? like in particular the whole point is that it shouldn't morally be on the .pc search path for the derivation that didn't declare a dependency on it | 11:05:07 |
| emily | it's just there to satisfy an internal requirement | 11:05:18 |
| Alyssa Ross | This would make it impossible to override dependencies, which is I think one of the points of pkg-config. | 11:05:27 |
| Alyssa Ross | In reply to @emilazy:matrix.org
like in particular the whole point is that it shouldn't morally be on the .pc search path for the derivation that didn't declare a dependency on it I don't think upstream would see it that way. | 11:05:48 |
| emily | In reply to @qyliss:fairydust.space
This would make it impossible to override dependencies, which is I think one of the points of pkg-config. hm, you mean like interposing a different dependency for a Requires.private without rebuilding the derivation that Requires.private it? | 11:06:19 |
| Alyssa Ross | Yes | 11:06:28 |
| K900 | Yeah | 11:06:28 |
