| 13 Feb 2024 |
 infinisil | 9999years: ^ | 18:20:01 |
| infinisil | it might be though, I need to take a closer look | 18:21:12 |
| infinisil | Same for your new PR (https://github.com/NixOS/nixpkgs/pull/288431) | 18:21:55 |
| 14 Feb 2024 |
|  @syphoxy:matrix.org changed their display name from sy to Stalled Engine. | 13:06:09 |
 Alexandros Liarokapis | Hi all. After much experimentation, I managed to add support for cross building using the precompiled "gcc-arm-embedded" toolchain. This includes taking care of the ccWrapper and binutilsWrapper. In order to avoid actually building gcc from source I had to use replaceStdenvStages and share the cross stages but change the last stage. Maybe it would be useful to add support upstream? It is non-trivial but very useful since it avoids building the toolchain for each difelferent arm-none-eabi configuration and the toolchain is already cached. The ideal way forward would perhaps be to add proper multilib support when cross building for many configurations like arm does with its toolchain. Is any of this worth considering for upstreaming to nixpkgs? | 15:54:39 |
| Alexandros Liarokapis | * Hi all. After much experimentation, I managed to add support for cross building using the precompiled "gcc-arm-embedded" toolchain. This includes taking care of the ccWrapper and binutilsWrapper. In order to avoid actually building gcc from source I had to use replaceStdenvStages and share the cross stages except the last one and properly handle float abis naming conventions and more. Maybe it would be useful to add support upstream? It is non-trivial but very useful since it avoids building the toolchain for each difelferent arm-none-eabi configuration and the toolchain is already cached. The ideal way forward would perhaps be to add proper multilib support when cross building for many configurations like arm does with its toolchain. Is any of this worth considering for upstreaming to nixpkgs? | 15:55:57 |
| infinisil | Ping John Ericson ^ | 16:39:44 |
 @qyriad:matrix.org | infinisil: what kind of solution would you prefer? re extendMkDerivation | 16:41:57 |
| infinisil | Qyriad: A solution that unifies existing approaches in a way as backwards compatible as possible, along with a plan on how the existing approaches can be cleaned up | 16:43:45 |
| infinisil | I guess in short: Making solutions converge instead of diverge (just adding more alternate approaches) | 16:44:49 |
| infinisil | * I guess in short: Making solutions converge (unifying and cleaning up approaches) instead of diverge (just adding more alternate approaches) | 16:45:05 |
| infinisil | This takes a whole bunch more effort, but is ultimately what we need to actually clean up Nixpkgs | 16:46:26 |
| @qyriad:matrix.org | is extendMkDerivation not a step in that direction though? it adds API surface but would reduce the complexity for the existing alternate approaches | 16:50:18 |
 9999years | yeah being able to get the functionality of overridePythonAttrs and overrideCabal in the existing overrideAttrs function is very appealing | 16:53:33 |
| 9999years | i'm a little nervous about the complexity of the code itself -- it seems like it's fairly easy to cause infinite recursion errors -- but it's definitely a step in the right direction | 16:54:12 |
| infinisil | Hm yeah if that's the case then it might be fine | 16:54:22 |
| infinisil | Oh yeah that's a big problem indeed, it's really tricky to get this right | 16:54:51 |
| 9999years | but any decision that lets us move forward is a good one, regardless of if we standardize on lib.mkExtendDerivation or lib.makeOverridableGeneric | 16:54:59 |
| infinisil | Robert Hensing (roberth) previously described that there's about 7 layers of fixed-points for some derivations | 16:55:13 |
| 9999years | and to be honest the makeOverridable code is no easier to read & comprehend | 16:55:19 |
| infinisil | It's just really hard to make sure that there are no regressions | 16:55:44 |
 Robert Hensing (roberth) | fixed-points and potential fixed-points. Not all of them are properly exposed etc | 16:55:52 |
| Robert Hensing (roberth) | which is part of the problem | 16:55:56 |
| infinisil | It's so many intricasies | 16:56:01 |
| Robert Hensing (roberth) | https://github.com/NixOS/nixpkgs/issues/273815 | 16:56:13 |
| @qyriad:matrix.org | In reply to @infinisil:matrix.org
It's just really hard to make sure that there are no regressions This is unfortunately going to be true of any unification solution and all of the steps towards them :/ | 16:58:22 |
| infinisil | Can't deny that! | 16:58:35 |
| Robert Hensing (roberth) | That's exactly why we need to burn it and start over with something manageable: a single fixpoint | 16:59:43 |
| Robert Hensing (roberth) | Each layer of fixpoint is expected to interact with each other layer. If they don't, that's a bug | 17:00:35 |
| Robert Hensing (roberth) | Let me refine that: if they completely don't, it's a missing feature that someone will want to use, in which case they'll write a partial implementation, which has bugs, because it doesn't interact with some of the other layers. | 17:01:31 |
