2 Sep 2024 |
Artturin | always prefix in addition to non-prefixed on native is where the always prefixing should start | 18:56:52 |
trofi | +1 | 20:11:13 |
emily | add prefixed → always pass --build and --host → remove non-prefixed? | 20:13:32 |
Artturin | Yep let's also add a flag to only have prefixed | 20:19:47 |
trofi | removing non-prefixed will be hard | 20:21:19 |
Artturin | Yep | 20:21:28 |
Artturin | especially for the end users | 20:21:38 |
trofi | Some tools embed the compiler names very deep, like wine build system. Or some code generators that assume /lib/cpp or equivalent. | 20:22:21 |
emily | Exherbo manage to do it | 20:22:39 |
emily | though their scope is also smaller | 20:22:42 |
emily | but presumably they at least package Wine. | 20:22:47 |
Artturin | Maybe a warning in the wrapper to advice users to use $CC | 20:22:55 |
emily | In reply to @artturin:matrix.org especially for the end users like for casual end-user CLI clang use? I wouldn't be opposed to figuring out a way to have a wrapper for that kind of thing | 20:23:26 |
emily | needing special cases for interactive use came up as part of Randy's macOS SDK rework already | 20:23:41 |
emily | seems okay for pkgs.{gcc,clang} to not quite be the cc packages from stdenv. | 20:24:05 |
trofi | https://bugs.gentoo.org/243502 is the rough scope of breakage. | 20:24:11 |
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 |