| 27 Jun 2025 |
 emily | not quite – there are reasons to forego standard headers and libraries even on a hosted platform | 21:05:39 |
| 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 |
