!OqhvaDMJdKYUicLDiE:nixos.org

Nixpkgs Stdenv

225 Members
74 Servers

Load older messages


SenderMessageTime
21 Dec 2024
@rosscomputerguy:matrix.orgTristan Ross
In reply to @philiptaron:matrix.org
Yessir.
Sounds good
21:48:30
@rosscomputerguy:matrix.orgTristan RossI'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
@philiptaron:matrix.orgPhilip 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
@philiptaron:matrix.orgPhilip Taron (UTC-8)Posted: https://discourse.nixos.org/t/community-team-updates/56458/11?u=philiptaron21:58:56
@rosscomputerguy:matrix.orgTristan Ross Oh 22:02:36
@rosscomputerguy:matrix.orgTristan Ross Yeah, I'm available on Tuesday to Thursday this week 22:03:56
@rosscomputerguy:matrix.orgTristan 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
@philiptaron:matrix.orgPhilip Taron (UTC-8)😬22:04:42
@rosscomputerguy:matrix.orgTristan RossIt's fine lol22:07:04
@philiptaron:matrix.orgPhilip 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
@rosscomputerguy:matrix.orgTristan RossYeah lol22:08:42
22 Dec 2024
@rosscomputerguy:matrix.orgTristan Ross

There's a few things that I've been thinking of:

  1. 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.
  2. cpu attribute which tunes everything from FPU, CPU model, architecture, etc. Generic names could be supplied which sets all options.
  3. CC without wrappers, possibly a shell hook which extends CFLAGS or other things and adds the necessary flags we need.
  4. 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
@rosscomputerguy:matrix.orgTristan Ross *

There's a few things that I've been thinking of:

  1. 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.
  2. 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.
  3. CC without wrappers, possibly a shell hook which extends CFLAGS or other things and adds the necessary flags we need.
  4. 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
@numinit:matrix.orgMorgan (@numinit)My $0.02 is that I'd definitely use option #2, especially when doing cross compiles04:29:20
@rosscomputerguy:matrix.orgTristan 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
@rosscomputerguy:matrix.orgTristan RossI 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
@rosscomputerguy:matrix.orgTristan 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
@rosscomputerguy:matrix.orgTristan 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:matrix.orgp14Fun, 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@stablejoy:matrix.org left the room.13:25:19
@reckenrode:matrix.orgRandy Eckenrode
In reply to @rosscomputerguy:matrix.org

There's a few things that I've been thinking of:

  1. 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.
  2. 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.
  3. CC without wrappers, possibly a shell hook which extends CFLAGS or other things and adds the necessary flags we need.
  4. 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:matrix.orgallrealmsoflife joined the room.15:55:33
@rosscomputerguy:matrix.orgTristan 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
@rosscomputerguy:matrix.orgTristan RossIt'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
@reckenrode:matrix.orgRandy EckenrodeBeing explicit about your build system would definitely be a big and breaking change.00:01:21
@philiptaron:matrix.orgPhilip Taron (UTC-8)It's worth doing, even it it might mean moving away from the "stdenv" name.14:37:05
@aliarokapis:matrix.orgAlexandros LiarokapisI was thinking about this, I really like what the conan package manager has done in this area. Basically keep a c/c++ "model" then translate into build-tool native integrations (eg toolchain files for cmake)16:21:52
@aliarokapis:matrix.orgAlexandros LiarokapisConan's model is very complete and takes cross compilation into account16:22:46
@rosscomputerguy:matrix.orgTristan Ross
In reply to @philiptaron:matrix.org
It's worth doing, even it it might mean moving away from the "stdenv" name.
Maybe, I'm 50/50 on that.
16:42:05
25 Dec 2024
@Ericson2314:matrix.orgJohn Ericson
In reply to @k900:0upti.me
Building arbitrary things for a UEFI target is generally not useful
We have bare metal targets despite few things building
17:32:50

Show newer messages


Back to Room ListRoom Version: 9