| 20 Mar 2025 |
 emily | then in that case it might be good, but in the current architecture we have it's better to have libiconv in stdenv than to try and get through 5,000 patches to add libiconv to deps lists because "it's needed on OpenBSD" | 21:18:54 |
| emily | since people will never reliably get it right if it only breaks on an obscure platform, and having (perceived-as-)noise in a package only required for one platform annoys people | 21:19:12 |
 John Ericson | what is the darwin situation? | 21:19:16 |
| emily | we add Apple's libiconv to stdenv | 21:19:24 |
| emily | we didn't use to, but we do as of the recent rewrite | 21:19:29 |
| John Ericson | :/ | 21:19:38 |
| emily | there was a lot of ++ lib.optionals stdenv.isDarwin [ libiconv ] before, which isn't even correct | 21:19:41 |
| John Ericson | we have "avoid mass rebuild" perverse incentive | 21:20:01 |
| John Ericson | it is easy to just bloat things more and more | 21:20:06 |
| emily | nothing to do with mass rebuilds | 21:20:13 |
| 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 |
