| 1 Jan 2026 |
 symphorien | as nativeBuildInputs sorry | 17:41:19 |
 sielicki | it exists as a setuphook in cmake | 17:41:22 |
| symphorien | and in this file, the value cmakeToolchainHook is built with the same stdenv as cmake | 17:42:22 |
| sielicki | your concern, if i understand correctly, is that the toolchain will be evaluated with the bare stdenv instead of the pkgsCross stdenv, yes? | 17:45:00 |
| symphorien | yes | 17:45:14 |
| sielicki | * your concern, if i understand correctly, is that the toolchain.cmake text file will be evaluated with the bare stdenv instead of the pkgsCross stdenv, yes? | 17:45:17 |
| symphorien | to fix it you should replace (stdenv.buildPlatform, stdenv.hostPlatform) by (stdenv.hostPlatform, stdenv.targetPlatform) | 17:46:06 |
| symphorien | but very few packages depend on targetPlatform | 17:46:37 |
|  zimward joined the room. | 17:46:40 |
| symphorien | and introducing new ones is not a light decision | 17:46:53 |
| symphorien | (if I undersant Alyssa Ross correctly) | 17:47:24 |
| symphorien | if the terminolofy about platforms is unclear I can try to explain more | 17:47:53 |
| symphorien | * | 17:48:01 |
| sielicki | my thought is that any given stdenv, regardless of whether it's exposed as pkgs.stdenv or pkgs.pkgsCross.foobar.stdenv, has buildPlatform and hostPlatform. buildPlatform is where it's building, hostPlatform is where it will run, and targetPlatform is just a notion for the antiquated gcc-ism where a compiler runs on buildPlatform but can only produce code for targetPlatform. | 17:49:26 |
| sielicki | I don't think that applies here, though. If stdenv.cc is set correctly, it encodes targetPlatform. cmake still only cares about buildPlatform and hostPlatform. No? | 17:50:22 |
| symphorien | no because your hook is built when building cmake | 17:51:00 |
| symphorien | so cmake is interested in the plaform where cmake will be executed (which will then be the build plaform, but when building the hook is the hostPlaform) and the targetPlaform | 17:52:02 |
| sielicki | I don't think the hook ought to be built when building cmake. That's kind of the point, the same cmake binary can be used with many different toolchain.cmake outputs | 17:53:31 |
| sielicki | regardless of whether I'm doing that atm in this repo | 17:53:52 |
| symphorien | when building pkgsCross.aarch64-multiplatform.opencv on x86_64, cmake and your hook are called with and stdenv with build=host=x86_64 and target=aarch64 whereas opencv is called with a stdenv with build=x86_64 and host=aarch64 and target is ill-defined | 17:54:28 |
| symphorien | then how do you plan for each derivation to choose the correct toolchain.cmake ? | 17:55:20 |
 Alyssa Ross | You will find a lot of agreement on this. | 17:58:21 |
| Alyssa Ross | We've moved away from implicit hooks for newer build systems | 17:58:31 |
| Alyssa Ross | In favour of having an e.g. cmakeBuildHook that does all the automatic stuff, and which can be built separately. | 17:59:16 |
| sielicki | symphorien: I don't think we even need to write the toolchain to the nix store as a derivation. I'm kind of spitballing here, but I guess this could just be a pure nix string handled by the existing lib.systems.parse code | 18:00:35 |
| sielicki | thanks all for the input, I'll play around a bit more with this | 18:03:16 |
 Sergei Zimmerman (xokdvium) | Speaking of the current cmake situation, the system where cmakeFlags and mesonFlags are constructed in make-derivation has quite big overhead. makeCMakeFlags and makeMesonFlags are one of the hotter functions in the whole of nixpkgs | 18:03:17 |
| Sergei Zimmerman (xokdvium) | It would be nice if the hooks were bound to the stdenv and were memorised accordingly | 18:03:51 |
| Sergei Zimmerman (xokdvium) | * It would be nice if the hooks were bound to the stdenv and were memoised accordingly | 18:04:04 |
| zimward | can someone explain to me why i get a gcc that targets x86_64-linux in a derivation from a stdenv that has riscv32-none-elf as its target? | 18:06:22 |
