| 21 Dec 2024 |
|  Dimitar joined the room. | 19:45:27 |
 Philip Taron (UTC-8) | I'd like to post this | 21:45:12 |
 Tristan Ross | In reply to @philiptaron:matrix.org
I'd like to post this On Discourse? | 21:47:20 |
| Philip Taron (UTC-8) | Yessir. | 21:47:27 |
| Tristan Ross | In reply to @philiptaron:matrix.org
Yessir. Sounds good | 21:48:30 |
| Tristan Ross | I'm thinking we can do a meeting sometime after the new year so we can figure things out for what the SC wants. | 21:50:31 |
| Philip Taron (UTC-8) | The sad (but also great) fact of the matter is that I'm most available over the next couple weeks, since I'm off of work. | 21:57:53 |
| Philip Taron (UTC-8) | Posted: https://discourse.nixos.org/t/community-team-updates/56458/11?u=philiptaron | 21:58:56 |
| Tristan Ross | Oh | 22:02:36 |
| Tristan Ross | Yeah, I'm available on Tuesday to Thursday this week | 22:03:56 |
| Tristan Ross | In reply to @philiptaron:matrix.org
Posted: https://discourse.nixos.org/t/community-team-updates/56458/11?u=philiptaron I thought you were meaning a different discourse post lol | 22:04:12 |
| Philip Taron (UTC-8) | 😬 | 22:04:42 |
| Tristan Ross | It's fine lol | 22:07:04 |
| Philip Taron (UTC-8) | I kept "who authored this" in there, so that if there's "hell no we aren't doing that" it would be clear where the stones ought to be thrown. Don't expect that, though. | 22:08:11 |
| Tristan Ross | Yeah lol | 22:08:42 |
| 22 Dec 2024 |
| Tristan Ross | There's a few things that I've been thinking of:
- Docs wise, try and promote using
packages.${system}.${name} over devShells due to runPhase and easy propagation of dependencies. inputsFrom is an option if a dev shell needs more stuff than just the package itself needs.
cpu attribute which tunes everything from FPU, CPU model, architecture, etc. Generic names could be supplied which sets all options.- CC without wrappers, possibly a shell hook which extends
CFLAGS or other things and adds the necessary flags we need.
stdenv without inheriting CC. Randy Eckenrode came up with this originally but I am thinking this might not be a bad idea. Tools like meson, cmake, etc could propagate cc which automatically should inject the hook.
| 04:27:06 |
| Tristan Ross | * There's a few things that I've been thinking of:
- Docs wise, try and promote using
packages.${system}.${name} over devShells due to runPhase and easy propagation of dependencies. inputsFrom is an option if a dev shell needs more stuff than just the package itself needs.
cpu attribute which tunes everything from FPU, CPU model, architecture, etc. Generic names could be supplied which sets all options. Support for different compilers would be better since it could have an attr set within each attribute that specifies what it should be for different compilers.- CC without wrappers, possibly a shell hook which extends
CFLAGS or other things and adds the necessary flags we need.
stdenv without inheriting CC. Randy Eckenrode came up with this originally but I am thinking this might not be a bad idea. Tools like meson, cmake, etc could propagate cc which automatically should inject the hook.
| 04:27:57 |
 Morgan (@numinit) | My $0.02 is that I'd definitely use option #2, especially when doing cross compiles | 04:29:20 |
| Tristan Ross | Yeah, #2 is something which I've been trying to work on for some time. I had a PR which adds a cpuModel attribute that is capable of it but it's been sitting stale from little to no reviews and constantly getting blocked with merge conflicts. | 04:31:32 |
| Tristan Ross | I likely would start fresh for doing #2 and drop the CPU model PR I originally made. Hopefully people could review that one and we could actually get it. | 04:32:10 |
| Tristan Ross | #3 and #4 are kinda big since it likely would break a lot. Might not be bad to work on those later on and do it right after a release when things are fixed. | 04:33:10 |
| Tristan Ross | #1 is more about educating more and it's more of a preferences things and down to how Nix is "taught/learned". | 04:33:38 |
 p14 | Fun, think I've found a case where gettext fails to build with symptoms like this: https://trac.macports.org/ticket/44387
But only if NIX_DEBUG is set. Presumably because there is some kind of build system race. I'm managing to trigger it with flto (fat objects) switched on with clang. Turning off NIX_DEBUG seems enough to make it work reliably (at least haven't observed the failure case). | 11:50:23 |
|  @stablejoy:matrix.org left the room. | 13:25:19 |
 Randy Eckenrode | In reply to @rosscomputerguy:matrix.org
There's a few things that I've been thinking of:
- Docs wise, try and promote using
packages.${system}.${name} over devShells due to runPhase and easy propagation of dependencies. inputsFrom is an option if a dev shell needs more stuff than just the package itself needs.
cpu attribute which tunes everything from FPU, CPU model, architecture, etc. Generic names could be supplied which sets all options. Support for different compilers would be better since it could have an attr set within each attribute that specifies what it should be for different compilers.- CC without wrappers, possibly a shell hook which extends
CFLAGS or other things and adds the necessary flags we need.
stdenv without inheriting CC. Randy Eckenrode came up with this originally but I am thinking this might not be a bad idea. Tools like meson, cmake, etc could propagate cc which automatically should inject the hook.
I’ve been advocating it, but I don’t think it was my idea. Maybe @emilazy:matrix.org? | 14:11:51 |
|  allrealmsoflife joined the room. | 15:55:33 |
| Tristan Ross | In reply to @reckenrode:matrix.org
I’ve been advocating it, but I don’t think it was my idea. Maybe @emilazy:matrix.org? Oh ok, I only know about it from you. | 18:12:07 |
| Tristan Ross | It's probably something we can definitely do but a bit down the road. Likely would break a lot of things. | 18:12:55 |
| 23 Dec 2024 |
| Randy Eckenrode | Being explicit about your build system would definitely be a big and breaking change. | 00:01:21 |
| Philip Taron (UTC-8) | It's worth doing, even it it might mean moving away from the "stdenv" name. | 14:37:05 |
