| 11 Jan 2025 |
|  pandapip1 joined the room. | 21:21:04 |
| 13 Jan 2025 |
 Toma | Updated my POC
https://github.com/NixOS/nixpkgs/pull/371613 | 01:15:33 |
| Toma | it is defined in terms of layers (the list of layers is currently static, but should be pretty straightforward to make extendible to be used by things like buildRustPackage.
and also finalAttrs is now actually the same as finalPackage
the cross stuff is not better than a few days ago, but I have at least read the splicing and bootstrapping implementations, which should help me | 01:16:08 |
| Toma | * it is defined in terms of layers (the list of layers is currently static, but should be pretty straightforward to make extendible to be used by things like buildRustPackage.)
and also finalAttrs is now actually the same as finalPackage
the cross stuff is not better than a few days ago, but I have at least read the splicing and bootstrapping implementations, which should help me | 01:16:28 |
 emily | fwiw finalAttrs.finalPackage.doCheck ≠ finalAttrs.doCheck | 01:20:23 |
| emily | finalPackage has post-processing | 01:20:37 |
| emily | and ideally splicing would be totally irrelevant to a new construct :) | 01:20:58 |
| emily | it's only there as a hack for backwards compatibility | 01:21:01 |
| Toma | In reply to @emilazy:matrix.org
fwiw finalAttrs.finalPackage.doCheck ≠ finalAttrs.doCheck well, it is the same now, since finalAttrs = finalPackage
The fix point IS the package | 01:30:49 |
| emily | how do you handle doCheck then? | 01:31:02 |
| Toma | It just "extends" the user given value.
(I used userValue.doCheck or ...canExecute..., but I could have done userValue.doCheck && ...canExecute...)
Just like you would extend nativeBuildInputs with by appending some hooks in the case of buildRustPackage
So even though the user wrote some value, the final value might have changed slightly.
There is currently a way to access all other layers (e.g. before doCheck was extended), but this introduces correctness problems. | 01:35:18 |
| Toma | * It just "extends" the user given value.
(I used userValue.doCheck or ...canExecute..., but I could have done userValue.doCheck && ...canExecute...)
Just like you would extend nativeBuildInputs by appending some hooks in the case of buildRustPackage or buildNpmPackage
So even though the user wrote some value, the final value might have changed slightly.
There is currently a way to access all other layers (e.g. before doCheck was extended), but this introduces correctness problems. | 01:36:06 |
| Toma | But do take a look at the implementation.
Also the lowest layer of transformation relies on the entirely undocumented builtins.derivationStrict | 01:37:55 |
| emily | right | 02:29:33 |
| emily | I'll try and take a look at some point (quite busy) | 02:29:39 |
| 14 Jan 2025 |
 ネコ | can someone look at #358042? it's a trivial fix and it's been preventing me from building any flakes for several months. | 17:08:45 |
| 15 Jan 2025 |
|  SomeoneSerge (nix.camp) changed their display name from SomeoneSerge (utc+3) to SomeoneSerge. | 19:02:58 |
| 16 Jan 2025 |
|  FliegendeWurst joined the room. | 09:37:40 |
| 17 Jan 2025 |
|  chintuchamar joined the room. | 04:40:34 |
| 20 Jan 2025 |
 Tristan Ross | I'm hoping to get https://github.com/NixOS/nixpkgs/pull/365057 approved so I can start working on LLVM bootstrapping without GCC. | 18:25:39 |
| emily | I still think that it's a major footgun and not an improvement over the status quo to have a toolchain variable that is only meant to set a bunch of defaults but that is nonetheless semantically significant and conditioned on in other code | 18:28:51 |
| emily | it might not be easy to figure out which factors the existing checks care about but it's the only way the change makes sense | 18:29:16 |
| emily | I think the best approach is just to omit toolchain entirely and simply split it up into its constituent factors | 18:30:08 |
| emily | it's possible some of the checks will end up checking the wrong thing but it's better than being able to do a check that defeats the point of splitting it up | 18:30:22 |
| Tristan Ross | Then we need a way to detect whether the toolchain is LLVM or not so the usingLLVM conditions can be translated. | 18:31:10 |
| Tristan Ross | * Then we need a way to detect whether the toolchain is LLVM or not so the useLLVM conditions can be translated. | 18:31:20 |
| emily | there's no such thing as "the toolchain is LLVM" | 18:31:23 |
| emily | that's what I keep trying to explain | 18:31:27 |
| emily | LLVM is a bunch of things and you can pick and choose which parts you use (compatibility permitting) | 18:31:36 |
| emily | hence Darwin using Clang, libc++, libc++abi, but ld64 | 18:32:15 |
