| 27 Jun 2025 |
 emily | but the obvious example is that glibc for aarch64-unknown-linux-gnu is of course built without glibc :) | 21:05:50 |
| emily | (but is definitely not building for bare metal) | 21:06:03 |
| emily | pkgs/build-support/bintools-wrapper/ld-wrapper.sh has an example of gnarly non-trivial logic we have in wrappers around the rpath stuff | 21:08:27 |
 Tristan Ross | In reply to @sielicki:matrix.org
with the current stdenv, my main complaint is that it's imprecise with respect to the languages supported. ie: there's no stdenv.cxx/stdenv.fc/stdenv.objcc/stdenv.objcxx/stdenv.nvcc/stdenv.hipcc This is something that's in the pipeline of changes we're working on. Hopefully soon we'll have some movement. | 21:23:25 |
| emily | it… is? :) | 21:27:44 |
| emily | I'm not aware of any current work on that front (for C-family languages I'm not sure it's a good idea to split up, though stdenvNoCC by default would obviously be great but is a hugely breaking change for external users) | 21:28:07 |
| Tristan Ross | In reply to @emilazy:matrix.org
I'm not aware of any current work on that front (for C-family languages I'm not sure it's a good idea to split up, though stdenvNoCC by default would obviously be great but is a hugely breaking change for external users) We've already got split GCC on the way and so far, it's doing good. | 21:35:20 |
| Tristan Ross | I was thinking of having derivations which mirror the toolchain attributes | 21:35:46 |
| Tristan Ross | So cc is your C/C++ compiler while cxxlib would be your C++ std implementation. | 21:36:19 |
| Tristan Ross | Ik it's something I've talked to Jon about | 21:37:22 |
| Tristan Ross | And it's in the stdenv & CC improvements plan | 21:37:39 |
| 28 Jun 2025 |
 Randy Eckenrode | I’ve been wondering if we should generate a sysroot when setting up the stdenv and point the compiler to that. It would simplify the Darwin SDK and let me drop some workarounds in the Swift compiler. | 00:30:39 |
| Randy Eckenrode | I would also like to see the stdenv not assume a C compiler and require it (and autotools/make support) to be added just like for every other language and build system. | 00:33:07 |
| Tristan Ross | Yeah, it'll be great to disconnect stdenv and cc | 00:33:53 |
| Tristan Ross | https://github.com/NixOS/nixpkgs/pull/409851 this is a part of that work | 00:34:47 |
| emily | In reply to @reckenrode:matrix.org
I’ve been wondering if we should generate a sysroot when setting up the stdenv and point the compiler to that. It would simplify the Darwin SDK and let me drop some workarounds in the Swift compiler. I think that would help, yes. have you seen Clang's support for per-target config files? | 08:24:50 |
| emily | those will be another piece of the puzzle | 08:24:56 |
| Randy Eckenrode | In reply to @emilazy:matrix.org
I think that would help, yes. have you seen Clang's support for per-target config files? No. I was assuming we would do that then pass it with -sysroot (or whatever it is). | 11:06:30 |
| Randy Eckenrode | If Clang lets us specify it in a config file, that’s better. | 11:06:50 |
| emily | https://clang.llvm.org/docs/UsersManual.html#configuration-files we can set an env variable to a directory that it will automatically load a file with command line args from based on language and target | 11:10:06 |
| emily | that doesn't quite solve cases where we have more complex logic based on other parameters or environment variables, but it is a substantial chunk of the no-compiler-wrappers puzzle | 11:11:35 |
| emily | and we could hopefully work with LLVM to find ways to eliminate as much custom logic as possible and find ways to move the rest into LLVM drivers | 11:12:34 |
| emily | I am not sure if the files support environment variable references but if they do then we could presumably do things like -mmacosx-min-version=$MACOSX_DEPLOYMENT_TARGET_salt etc. | 11:14:44 |
| emily | though doesn't quite help for static SDL stuff which may be the only remaining reason to care about salts for Darwin soon :P | 11:15:38 |
| emily | *SDK | 11:15:43 |
| emily | if someone wanted to prototype this I think it should be possible to make a derivation that extracts the relevant flag files from cc-wrapper and writes them into a directory with config files like this for all three platforms, and then you could try arranging an stdenv that exposed unwrapped LLVM directly with the relevant path variable set | 11:18:38 |
| emily | since it searches for a file without the triple we can use it to implement a default target too although obviously we'd ideally prefer always passing a target - we can do always-prefixed compilers without wrappers because I believe that Clang interprets being invoked through a foo-clang symlink like clang -target foo | 11:21:13 |
| emily | (but ideally you'd want the multi target Clang lying around as well - not sure if you can configure it to refuse to build without being given an explicit target but that sounds very much like something we could work with upstream on) | 11:22:16 |
| emily | I'm not sure how we'd achieve the libc vs. no libc flags stuff but maybe we can do away with it if we use the correct include flags etc. | 11:26:23 |
| emily | I believe it should be possible to construct a basic LLVM toolchain for both Linux and macOS that does not use wrappers for at least Clang (less sure about things like LLD without more upstream work) and that completely ignores targetPlatform | 11:28:55 |
