| 21 Jul 2025 |
 emily | that can be a Python script calling Python functions :) but sure, I'm not saying Bash has 0 utility. but if you start doing type checks in it it becomes time to reconsider | 14:39:23 |
| emily | like hopefully more hooks etc. can be Python in future even | 14:39:33 |
| emily | there's an open PR to get python3Minimal to 0 deps so we can use it freely for build stuff | 14:39:53 |
 connor (he/him) (UTC-7) | I guess this might have been cleaner as a Python script: https://github.com/NixOS/nixpkgs/blob/9967bf134c435416240b80b206b36fd5fff0d6b1/pkgs/development/libraries/science/math/magma/generic.nix#L235 | 14:40:32 |
| emily | I think this isn't horrible, but it's at about the maximum Bash I can stomach before I start wishing it wasn't | 14:41:45 |
 Alexandros Liarokapis | I wonder if an a main model object for each package like https://docs.conan.io/2/reference/conanfile/methods/package_info.html#cpp-info-library-and-build-information would be useful. Then stdenv hooks would modify the model, not the flags directly. This among other things allows for cflags deduplication in contrast to the adhoc approach of just appending strings like currently. Conan is having great success producing build-tool specific integrations as well by also keeping build-tool-specific metadata for each package and having a unified model for each build tool. Helps avoid gcc wrappers etc. | 22:12:35 |
 Randy Eckenrode | That sounds like something I suggested a while back where packages would have a build-system, which would modify the derivation with whatever configuration it needs. | 23:57:53 |
| Randy Eckenrode | However, it seems that hooks written in Bash seem to be the preferred way of doing things. | 23:58:21 |
| 27 Jul 2025 |
 John Ericson | ah GCC's spec files are at least morally similar | 16:36:03 |
| John Ericson | yeah, I like the idea of paying to make everything doable with spec files and these config files along | 16:36:22 |
| John Ericson | mmmm very good | 16:36:23 |
| emily | it does mean that we can no longer solve problems in wrappers at all and have to pay the costs of contributing to drivers for anything we end up needing | 16:42:47 |
| emily | which is a bit painful | 16:42:49 |
| emily | e.g. I am adding -fmacro-prefix-map to cc-wrapper right now | 16:43:01 |
| emily | figuring out how LLVM would want a "map away all hashes in the Nix store for __FILE__" feature to look would be substantially higher-cost/longer-time | 16:43:19 |
| John Ericson | emily: well we don' | 16:51:52 |
| John Ericson | * emily: well we don't have to do 100% one or the oher | 16:51:59 |
| John Ericson | * emily: well we don't have to do 100% one or the other | 16:52:01 |
| emily | most of the benefits only happen when you 100% eliminate wrappers | 16:53:00 |
| emily | e.g. libclang used by Rust bindgen | 16:53:05 |
| emily | is inherently working with an "unwrapped compiler" and this causes issues | 16:53:13 |
| emily | and it is hard to be fully multi-target with wrapping | 16:53:33 |
| John Ericson | well I would rather make the investment in hopes we can someday get 100% | 16:54:00 |
| John Ericson | like, if we shoot to 100% in the first go, we may well die trying | 16:54:35 |
| John Ericson | but if we shoot for "as far as we can get before it gets too hard", and know we won't get to 100%, we can get to somewhere else without tears and budget overruns | 16:55:35 |
| John Ericson | and then we can later circle back, maybe in a later funding round when we have more budget on the basis of earlier successes :) | 16:56:24 |
| 28 Jul 2025 |
| Randy Eckenrode | And Swift’s built-in Clang driver. | 00:36:22 |
| Randy Eckenrode | I’m trying really hard not to use a wrapper with Swift. | 00:36:41 |
| Randy Eckenrode | * And Swift’s built-in Clang driver/importer. | 00:37:20 |
|  siraben joined the room. | 07:02:28 |
