| 1 Jan 2026 |
 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 |
| 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 |
