| 15 Nov 2024 |
 p14 | :nixos intensifies: | 12:53:32 |
| p14 | https://github.com/NixOS/nixpkgs/pull/356189 | 14:52:14 |
| 17 Nov 2024 |
 emily | do we have something in the wrappers for flags specifically for C, not for C++? | 08:56:53 |
| emily | because a bunch of lines of cc1plus: warning: '-Werror=' argument '-Werror=implicit-int' is not valid for C++ on every C++ compilation seems bad | 09:00:16 |
 trofi | I don't think so. In theory it could be implemented as an else part in https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/cc-wrapper/cc-wrapper.sh#L143 | 10:59:05 |
| trofi | But generally cc-wrapper is not very precise WRT language-specific options. | 11:00:04 |
| emily | right | 11:01:23 |
| emily | I commented on https://github.com/NixOS/nixpkgs/pull/356545#issuecomment-2481063257 that it may be better to just update to the Git GCC 14. | 11:02:06 |
| emily | since we have to do patch backport work and getting the flags in is awkward. | 11:02:16 |
| emily | the alternative would be to backport even more patches to set the defaults in GCC itself, which would then make pinning gcc13 not work as expected, and also be more work | 11:02:37 |
| trofi | On my system c23 will break at least 80 packages: https://trofi.github.io/posts/326-gcc-15-switched-to-c23.html, about 4% of packages. All of nixpkgs will have quite a few more. | 17:47:50 |
| emily | 🫠| 17:49:01 |
| emily | 4% didn't seem so bad until I saw the list | 17:49:04 |
| 18 Nov 2024 |
|  yannis changed their display name from yannis to yannis|pto_back_nov_26. | 10:40:11 |
 sterni | emily: I don't get why we aren't using env or something instead of execline, surely coreutils or busybox are better optimised w.r.t. closure/bootstrapping? | 15:11:53 |
| emily | IIRC env doesn't work because of CLI arguments or something. https://github.com/NixOS/nixpkgs/pull/324071 originally just used a tiny inline C program but got bikeshedded into using execline because it's there | 15:12:30 |
| emily | I would be okay just doing the tiny inline C program thing | 15:12:35 |
| emily | right, we can't do env -- because we want it to be a binary path rather than an argv | 15:12:53 |
| emily | though some of the other things in there will already break if you give them options so maybe we should be doing wrappers of some kind anyway | 15:13:10 |
| emily | the advantage of our own tiny C program is that it inherently doesn't depend on fetching. | 15:14:08 |
| sterni | It's a bit silly that we can't really return the empty string. | 23:55:21 |
| 19 Nov 2024 |
| emily | yeah. well, it makes sense that we want something that's usable as an argv[0] | 00:08:01 |
| emily | I lean towards just vendoring the C program, but if that doesn't fly I feel like my PR is an improvement. | 00:08:29 |
|  @midirhee12:tchncs.de joined the room. | 05:45:33 |
| sterni | Why is the dependency closure a concern anyways? | 13:53:34 |
| sterni | I think I don't understand the problem yet we are trying to solve | 13:53:42 |
| emily | in the case of https://github.com/NixOS/nixpkgs/pull/351768 it meant >100 more builds to test stdenv changes just because of doing the right thing to handle cross | 13:55:26 |
| emily | the hack works, but it seems basically suboptimal that switching from canExecute to the more general and capable emulator stuff brings in a bunch of stuff, especially in weird platform/cross scenarios | 13:56:28 |
| emily | I mean I thought the original C program was fine | 13:56:38 |
| emily | it just doesn't seem that sensible to be pulling in a bunch of deps for a manpage build for a core stdenv function | 13:57:04 |
