| 2 Sep 2024 |
 trofi | (apparently mono also hardcodes as) | 20:24:31 |
 emily | https://gitlab.exherbo.org/exherbo/virtualization/-/blob/master/packages/app-emulation/wine/wine.exlib?ref_type=heads
heh:
edo mkdir shims
edo ln -s /usr/host/bin/$(exhost --tool-prefix)nm ./shims/nm
edo ln -s /usr/host/bin/$(exhost --tool-prefix)as ./shims/as
edo ln -s /usr/host/bin/$(exhost --tool-prefix)ar ./shims/ar
edo ln -s /usr/host/bin/$(exhost --tool-prefix)ranlib ./shims/ranlib
| 20:26:29 |
| emily | we could have a separate package that provides unprefixed compilers so that at least we know which packages are broken | 20:26:52 |
| emily | that would be a smoother off-ramp from unprefixed tools | 20:27:03 |
| trofi | As long as you document what interface nixpkgs expects from upstream packages and provides to nixpkgs users it should be fine. But it's hard. It's hard even for a seemingly simple CFLAGS interface :) | 20:28:20 |
| emily | hell is other people's build systems | 20:31:32 |
| emily | sometimes I wish we could do a gittup/google3 and just write our own builds for every package :) | 20:31:56 |
| trofi | Sounds like a disaster :) | 20:32:33 |
| trofi | AFAIU google3 uses somewhat reasonable ./configure && make && make install for many third-parties. I don't think Google maintains it's own, say, openssl build system. | 20:33:22 |
| emily | BoringSSL has a public Bazel build system | 20:34:41 |
| trofi | It's not a thirt-party :) | 20:34:54 |
| emily | I thought they used BoringSSL over OpenSSL in general | 20:35:12 |
| emily | my understanding is that there is heavy pressure to Bazel all the things, though I'm sure it's not completely universal | 20:35:15 |
| emily | I have definitely heard "it's not relevant for Google because they just use their own build system" before, at least | 20:35:40 |
| trofi | Google is big :) | 20:36:59 |
| trofi | It's hard to get uniformity in a huge company. And one has to co-exist with an external world. Thus there are places where openssl has to be used as-is. | 20:38:01 |
| emily | right | 20:39:27 |
| emily | I thought there was policy around BoringSSL specifically but I'm just an outsider who occasionally hears whispers | 20:39:56 |
 Alyssa Ross | if only there was a better OpenSSL build system tho | 20:40:00 |
| emily | I'm sure there's very few properties that hold across the entirety of google3 | 20:40:05 |
| Alyssa Ross | I hate having to keep adding entries to the mapping of platforms to OpenSSL config names | 20:40:18 |
| emily | we could just ship BoringSSL! | 20:40:26 |
| emily | (probably we couldn't) | 20:40:29 |
| Alyssa Ross | almost certainly not lol | 20:40:45 |
| emily | there should be branding flags so that if you're not inside Google it calls itself ExcitingSSL | 20:41:08 |
| trofi | Gah, I stand corrected. Both boringssl and openssl proper(openssl_vendor) use local implementation of the build system and don't seem to rely on the original one any more. sudo is a bit closer to the original (just as an example of a package). | 20:53:08 |
| 4 Sep 2024 |
|  SomeoneSerge (utc+3) changed their display name from SomeoneSerge (UTC+3) to SomeoneSerge (nix.camp). | 21:48:44 |
| 6 Sep 2024 |
| emily | an awful lot of packages seem to manually set a bunch of --<foo>dirs that are already set by stdenv. what's up wi that? | 12:37:42 |
| emily | * an awful lot of packages seem to manually set a bunch of --<foo>dirs that are already set by stdenv. what's up with that? | 12:37:45 |
| emily | e.g. jq:
configureFlags = [
"--bindir=\${bin}/bin"
"--sbindir=\${bin}/bin"
"--datadir=\${doc}/share"
"--mandir=\${man}/share/man"
| 12:37:56 |
