| 20 Mar 2025 |
 emily | like, if we could mask parts of libc on every platform so you have to specify libiconv, then maybe? | 21:06:57 |
| emily | but what actually happens is that people write packages for the couple of platforms they have access to and then it breaks on other ones | 21:07:15 |
 Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | (i wasn't quite certain, this is very low in dep tree, but not stdenv on all platforms) | 21:07:33 |
| emily | shrinking stdenv is a noble goal in general, but we have tons of build tooling in there already. I think that bundling libraries for things that are in libc on the vast majority of supported platforms makes sense | 21:07:45 |
| emily | in particular there might be a platform with a super tiny libcore and then they have libfs and libmath and so on | 21:08:07 |
| emily | that would be elegant and in an ideal world we'd specify those explicitly | 21:08:13 |
| emily | but in practice if we wanted to support it in Nixpkgs, we'd bundle all of them into stdenv, and I think that's a perfectly reasonable trade-off, even if it's not the most beautiful possible world. adding libmath everywhere would just piss people off and usually not happen | 21:09:03 |
 John Ericson | that was the hope | 21:16:53 |
| 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 |
