| 29 Dec 2025 |
|  n3tcat set a profile picture. | 02:24:47 |
|  n3tcat left the room. | 02:33:13 |
| 1 Jan 2026 |
 symphorien | do you think it would be a problem to make cmake depend on targetPlatform ? so that it has some options preconfigured with knowledge of it ? | 17:28:34 |
| symphorien | see the discussion on #users:nixos.org | 17:28:52 |
|  whispers (it/fae) joined the room. | 17:30:03 |
|  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 |
