 | Nixpkgs Stdenv | 189 Members |
| 59 Servers |
| Nixpkgs Stdenv | 189 Members |
| 59 Servers |
| Sender | Message | Time |
|---|---|---|
| 27 Jun 2025 | ||
 emily | yes, it's magic builtin stuff | 19:51:13 |
| emily | I think builtins.fetchurl is a wrapper around it or something (probably newer than <nix/fetchurl.nix>?) | 19:51:23 |
| emily | or vice versa | 19:51:24 |
 sielicki | turtles all the way down | 19:51:40 |
| sielicki | okay, yes, it's right in the root of libexpr | 19:52:25 |
| emily | actually I think the difference is that <nix/fetchurl.nix> produces an actual FOD | 19:52:41 |
| emily | whereas builtins.fetchurl is a bulitin fetcher that runs at eval time | 19:52:48 |
| emily | but don't quote me on that | 19:52:49 |
| sielicki | it's a shame that this is so difficult to touch without catastrophic levels of rebuilds | 20:00:24 |
| emily | you can override stdenv for individual packages though of course for bootstrap that does not help | 20:01:38 |
| emily | but for anything early in bootstrap you can just build early bootstrap stuff when iterating since ideally it gets "washed out" past a certain point anyway | 20:02:12 |
| sielicki | 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 | 20:04:36 |
| sielicki | there's really no good reason that a C compiler implies a C++ compiler or vice versa. I'm looking at this in the context of generating cmake toolchains from stdenvs | 20:05:14 |
| emily | in an ideal world stdenvNoCC would be the default and C toolchains would be added explicitly as dependencies | 20:13:49 |
| emily | I doubt we'd realistically decouple C and C++ though | 20:14:00 |
| sielicki | one of the biggest rough spots for me is in trying to setup environments between clang/gcc and libc++ vs libstdc++: both of these stdenvs are capable of building C++ programs | 20:25:44 |
| emily | libcxx is the LLVM C++ library | 20:37:24 |
| emily | on Linux we use libstdc++ by default | 20:37:28 |
| emily | well, I guess you know that :) | 20:37:35 |
| emily | but I'm not sure why you're looking at stdenv.cc.libcxx to begin with, what are you trying to accomplish? | 20:37:44 |
| sielicki | I dunno, that's a good question. I guess my main idea here is to avoid cc-wrapper as much as possible, for build systems where it is possible. In the case of autotools, I don't see a way around cc-wrapper. But for meson or cmake, I think passing the unwrapped compiler, alongside a nix-generated toolchain, can help out in some hand-wavey way. https://github.com/sielicki/nix-cmake/blob/main/pkgs/cmake-toolchain-hook/cmake-toolchain.nix https://github.com/sielicki/nix-cmake/blob/main/pkgs/cmake-dependency-hook/cmakeBuildHook.cmake this is very rough but it's a start. | 20:43:57 |
| emily | we (or at least I) would generally like to move in the direction of fewer wrappers, but it's hard (will require upstream compiler work) | 20:45:12 |
| emily | since exactly what the flags inject depends on what flags are being passed | 20:45:18 |
| emily | I think that is generally hard to express in the toolchain information files build systems support | 20:45:32 |
| sielicki | hmm, I'm not sure I see why -- what's something we can accomplish with cc-wrapper that we can't do otherwise? | 20:47:00 |
| emily | e.g., we look at -nostdlib/-nostdinc when deciding what flags to inject | 20:55:05 |
| emily | which is import for things like getting libc to work without breaking freestanding builds (including libc itself) | 20:55:58 |
| emily | perhaps not a common use-case for CMake, but pretty critical for our compilers to work :) | 20:56:16 |
| emily | there is also stuff about cross-compilation role variable demangling but theoretically a sufficiently clueful build system could handle that sort of thing (otoh CMake is pretty bad at cross in practice) | 20:57:16 |
| sielicki | I'm probably missing context on the specifics, but I'd think those would be different stdenvs (and different triples) -- freestanding corresponding to something like aarch64-none-elf and used to bootstrap something like aarch64-unknown-linux-eabi, right? | 21:04:29 |