| 20 Mar 2025 |
 emily | we rewrote the entire stdenv | 21:20:20 |
| emily | FWIW, Apple's libiconv is effectively part of the system library on macOS insofar as they only compilation environments they ship have direct access to it | 21:20:24 |
| emily | there's never a case where you could be compiling software for macOS in any normal way and not have libiconv right there | 21:20:37 |
| emily | you do need -liconv, and we explicitly don't inject that | 21:20:51 |
| emily | build systems have to get that right, which they mosly do | 21:20:56 |
| emily | * build systems have to get that right, which they mostly do | 21:20:57 |
 John Ericson | as we were discussing before with compiler-rt | 21:20:59 |
| John Ericson | libc is just a bad layer of abstraction | 21:21:07 |
| John Ericson | and it's very viral | 21:21:10 |
| John Ericson | it is frustrating | 21:21:27 |
| emily | I think us establishing some baseline API that gets offered for C programs even if it has to be composed out of multiple packages is not really the worst thing in the world | 21:22:15 |
| emily | even if we had everything perfectly factored out into totally orthogonal pieces on every platform, I think people would be unhappy about writing 50 lines of boilerplate for libraries that are "always there" in every single package | 21:22:46 |
| emily | stuff like factoring out autotools assumptions is much higher-value IMO | 21:22:55 |
| John Ericson | there should be some baseline API | 21:23:25 |
| John Ericson | but "repeating the boilerplate is annoying" is rather a slipperly slope | 21:23:37 |
| John Ericson | because adding more stuff always cuts more downstream dependenices | 21:23:49 |
| John Ericson | no disagreement | 21:24:05 |
| John Ericson | what I mean by mass rebuild is I guess is more just changing hte foundations | 21:24:30 |
| John Ericson | and then fixing all the packages | 21:24:33 |
| John Ericson | few people want to do that | 21:24:37 |
| John Ericson | we need to get the resources somehow | 21:24:46 |
| John Ericson | there is nothing hard about getting out the autotools assumption | 21:24:53 |
| John Ericson | it is just a lot of annoying work | 21:24:57 |
| John Ericson | CA derivations are supposed to help with these things RIP | 21:25:07 |
| John Ericson | (that was my thought so many year ago) | 21:25:17 |
| John Ericson | they still could, to be clear, but just ugh | 21:25:30 |
| emily | I don't think avoiding rebuilds is really a motivation there. we rebuild the entire package set every couple weeks | 21:25:48 |
| emily | it's the manual toil | 21:25:53 |
| John Ericson | emily: the thing that got me before was making a slight tweak to a stdenv script and then rebuilding everything serially, the dream with CA derivations was you could, assuming most things will have the same result, try to rebuild everything in parallel / out of order, using their previous dependencies | 21:38:12 |
| John Ericson | long bootstrapping chains meant lots of O(n) rebuilds when I'd notice a mistake in the things I did to stdenv in some downstream package | 21:39:02 |
