| 1 Jan 2026 |
|  sielicki joined the room. | 17:30:54 |
 Alyssa Ross | Generally we try to avoid targetPlatform | 17:31:00 |
| Alyssa Ross | It might be less objectionable once to do it in the CMake hooks once they're separated from the cmake package. | 17:31:17 |
| sielicki | the context is this idea: https://github.com/sielicki/nix-cmake/blob/main/pkgs/cmake-toolchain-hook/cmake-toolchain.nix | 17:31:39 |
| sielicki | targetPlatform is used unnecessarily there, I only use it as a comment to identify the stdenv (probably, incorrectly/imprecisely) | 17:32:48 |
 symphorien | so on x86 when you build pkgsCross.aarch64-multiplatform.something_that_uses_cmake, when building cmake, the hostplatform is x86 (the one running cmake) the buildplatform is x86 and only the targetplatform is aarch64 | 17:34:43 |
| sielicki | hostPlatform is aarch64, no? | 17:35:24 |
| symphorien | if I understand correctly your proposal is to make cmake effectively a cmake-wrapped-with-its-toolchain-config | 17:35:33 |
| Alyssa Ross | for cmake it's x86_64 | 17:35:36 |
| Alyssa Ross | hostPlatform is the platform the package runs on. you are running CMake on x86_64 | 17:35:51 |
| symphorien | when building cmake the hostplatform is the platform running cmake, so the buildplatform of, say, opencv if you are building opencv | 17:36:10 |
| sielicki | cmake pulls in this hook the same way that it pulls in its current build hooks, so this doesn't build at the same time that cmake does | 17:38:29 |
| symphorien | are the hooks built with the same stdenv as cmake ? | 17:38:56 |
| sielicki | this hook doesn't depend on cmake, either -- it's purely a transformation from properties on stdenv to /some text file/, which just so happens to be readable by cmake | 17:39:14 |
| sielicki | I guess they can be, but they don't have to be. | 17:39:33 |
| symphorien | then do you mean one would have to add your hook to all derivations as buildInputs ? | 17:39:54 |
| 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 |
