| 15 Nov 2024 |
 p14 | (and fix it) | 11:21:57 |
 emily | here's the sketch: for every derivation producing a shared library, you want to use llvm-ifs to generate stubs from the libraries. you put those in dev, say | 11:22:08 |
| p14 | Makes sense. | 11:22:17 |
| emily | downstream derivations do not consume the library output at build time. they consume dev exclusively | 11:22:23 |
| emily | and dev is ca-derivations | 11:22:32 |
| emily | (can you have only some outputs be CA? probably not. so it's a pain with Nix already) | 11:22:39 |
| emily | (but you can split it up into a separate derivation, etc.) | 11:22:44 |
| p14 | For the prototype is there a reason you can't make whole derivations ca, even if they are not reproducible? | 11:23:20 |
| emily | you then, as part of the final package fixed-point-taking, join up every package that depends on a stub with the corresponding actual library output, and patch up the executables to point to the real paths. (optional: fancy static dynamic loading stuff goes here for perf) | 11:23:21 |
| emily | that's pretty much it. rebuilds of build tools still rebuild a lot | 11:23:34 |
| emily | but if you change the implementation of a function in OpenSSL without adding or removing any symbols, and don't touch the headers, then the only rebuilds are executables that use OpenSSL and things depending on them | 11:23:54 |
| p14 | Well, you could imagine trying to make the build tool that does the patching as small and reproducible as possible. | 11:24:02 |
| emily | and the executable rebuilds are really cheap | 11:24:08 |
| emily | just some patching | 11:24:10 |
| emily | so if you eliminate OpenSSL from your build tools, that means that OpenSSL updates become ~free | 11:24:15 |
| emily | a few thousand seds, basically | 11:24:20 |
| p14 | Sketch makes sense. | 11:24:32 |
| emily | I wouldn't be opposed to helping trying to implement it, at least in the form of "oh, this is how you should handle X" | 11:24:53 |
| emily | I doubt Nixpkgs will ever adopt this system, though | 11:24:59 |
 aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | In reply to @emilazy:matrix.org
here's the sketch: for every derivation producing a shared library, you want to use llvm-ifs to generate stubs from the libraries. you put those in dev, say Looks like libgl or vulkan-loader | 11:25:01 |
| aleksana 🏳️⚧️ (force me to bed after 18:00 UTC) | Makes sense | 11:25:04 |
| emily | sufficiently ambitious projects like this go in my "for the Nix successor" folder :) | 11:25:15 |
| emily | In reply to @aleksana:mozilla.org
Looks like libgl or vulkan-loader yeah, except we patch in the final location at build-time | 11:25:23 |
| emily | so everything is still as early-bound, we just skip a lot of building when we know it would produce the same result | 11:25:34 |
| p14 | In reply to @emilazy:matrix.org
sufficiently ambitious projects like this go in my "for the Nix successor" folder :) Right, so, where do we start boiling the ocean from? ;-) | 11:25:41 |
| emily | this is really key to exploiting ca-derivations, because it's not very useful to know a library didn't really change if the actual library you build against changes | 11:25:52 |
| emily | and it's really silly that Unix merges the interface and implementation into one file | 11:26:02 |
| emily | builds don't look at the object code of the dynamic libraries they link against. why is it in the same file? | 11:26:19 |
| emily | In reply to @p14:matrix.org
Right, so, where do we start boiling the ocean from? ;-) I've got a five year plan… | 11:26:40 |
| emily | (probably an underestimate) | 11:26:55 |
