| 13 Aug 2025 |
 Alyssa Ross | Imagine cross compiling from glibc to musl, or x86_64 to i686 | 18:05:38 |
 maralorn | I mean I also find the code around that very confusing because it has "otherBuildInputsSystem" and "otherBuildInputs" which are both used and there is a TODO there. | 18:05:48 |
| Alyssa Ross | Cross compiling doesn't necessarily mean you can't execute | 18:05:50 |
| maralorn | I see. Fair. | 18:06:10 |
| Alyssa Ross | Which is why we have a predicate in Nixpkgs called canExecute, which stdenv uses to decide whether to have checkPhase and reference checkInputs and nativeBuildInputs | 18:06:14 |
 emily | (btw I have solved the LLVM 12 problem. still a WIP draft locally. but my experiment was a success) | 18:06:49 |
| emily | (it is a joyous occasion) | 18:07:05 |
| Alyssa Ross | * Which is why we have a predicate in Nixpkgs called canExecute, which stdenv uses to decide whether to have checkPhase and reference checkInputs and nativeCheckInputs | 18:07:40 |
| maralorn | So in this case we would want Z3 to be compiled for the target plattform, right? And for that it should be nativeCheckInputs and not checkInputs? | 18:07:40 |
| Alyssa Ross | We would want it to be for the build platform, I thought | 18:07:54 |
| emily | I assume the library invokes Z3 at runtime | 18:08:05 |
| Alyssa Ross | Since PATH was mentioned. | 18:08:06 |
| emily | so you want it for the host platform | 18:08:08 |
| emily | (you almost never want to say "target platform") | 18:08:15 |
| maralorn | Aaah, yeah. | 18:08:15 |
| emily | (unless what you are building is a single-target compiler) | 18:08:23 |
| Alyssa Ross | With strictDeps I believe checkInputs don't end up in PATH, only nativeCheckInputs | 18:08:34 |
| emily | I think we have a HOST_PATH thing or something. | 18:08:50 |
| emily | for patchShebangs --host I guess. | 18:09:05 |
| emily | but yeah cross testing is a mess. even with canExecute. | 18:09:11 |
| emily | tbh I think it's fine to use whatever variable is convenient and leave it to the future generation that decides it wants to figure out how cross tests should work. | 18:09:24 |
| emily | (to which the answer will be "separate installCheckPhase derivation" if we raised them well) | 18:09:36 |
 Artem | to be clear: Z3 is called by the test suite when the test suite is run | 18:12:10 |
| Alyssa Ross | that's a nativeCheckInputs case then, definitely | 18:13:32 |
| Artem | simply replacing testSystemDepends with nativeCheckInputs here doesn't work. I'm happy to do anything before I open a PR if someone tells me what :-) otherwise I proceed with this | 18:14:25 |
| Artem | * simply replacing testSystemDepends with nativeCheckInputs here doesn't work. I'm happy to do anything before I open a PR if someone tells me what :-) otherwise I proceed with testSystemDepends | 18:14:32 |
| Alyssa Ross | It sounds like there needs to be another builder option, testSystemNativeDepends or some less terrible name, that maps to nativeCheckInputs | 18:16:55 |
| emily | (I don't see how. if you're cross-compiling a system that uses this thing, then it's going to invoke the hostPlatform Z3 when you actually use it) | 18:18:32 |
| Alyssa Ross | But it's the test suite that runs the binary | 18:18:49 |
| emily | (testing it against the build platform Z3 is strictly less realistic for testing whether the thing you are building will actually work) | 18:18:50 |
