New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stdenv: make checkInputs native #53440
Conversation
We can't run the checkPhase when build != host, so we may as well make the checkInputs native. This signicantly improves the situation of Python packages when enabling strictDeps.
Mmm libraries/modules/whatever should generally be |
In the case of Python it would mean putting the test runner / executables in |
Hmm? That doesn't seem wrong on the face of it. I did a little thought experiment earlier today to try to tease out how things should work: Suppose we are running tests in a cross build with wine. We already run Wine runs on the build platform (it's host is our build). It doesn't produce machine code but it it accepts it; so we can say it's target platform is windows, our host. So it's build -> host, i.e. in would-be-called- Python in all cases accepts machine code on the same platform as it runs. We could think either it's host = target or say it doesn't have a target (unconstrained target, build hashes not target sensitive). Under the former interpretation (host = target), The python library "builds" are machine independent in principle, but of course could link windows-specific stuff, so their host=our host. (And then there's cython pipi or whatever). Most of this is again target agnostic, but if it was (say if somebody wrote an Android-targetting forth compiler in Python haha) we have their target = our target. This means So based on the above, |
Aside from indeed using an emulator during
This should be done in the --- Edit A bit more about the emulator and |
In #53445 I'll continue under the assumption we can use |
Perhaps we just do that for now, and not worry about the emulator case. Otherwise, perhaps |
If we ever get tests to work on cross builds, we are going to need to resplice everything, so the "correct" behavior is to be determined. Defining checkInputs as "a native build input that is only added when doCheck = true" seems reasonable here. Most likely we will need to resplice all of the nativeBuildInputs so that they can run inside the emulator so we still have access to things like |
As @matthewbauer said, we can improve this later on. Merging... |
Err I still think this is a bad idea. |
If there really is a wrapper process, one should not be able to access nativeBuildInputs, if build = host, then we get this for free. |
I don't care either way, really, I used `buildInputs` because it seemed a sane choice at that moment, but I would expect nativeBuildInputs and buildInputs to do the same thing when build == host, hence the only question from me here is why does this even make a difference if we assume build == host situation to be the default for running tests, i.e.
This signicantly improves the situation of Python packages when enabling strictDeps.
Why?
|
Otherwise we would have to split everywhere the test runner (and possibly others) from other test dependencies, and we already have hundreds of expressions already using this. Also, unless we introduce a --- edit
|
@oxij the point of |
We can't run the checkPhase when build != host, so we may as well make
the checkInputs native.
This signicantly improves the situation of Python packages when enabling
strictDeps.
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)