Wooo! Long wanted to do this; it's a huge benefit to native users on this. The one thing is actually I think we need to do allowedReferences on the other deps, rather than disallowedReferences on those deps, because of the case where something is a both a build-time and run-time dep in the native build.

The other issue was that dev inputs sometimes do depend on build time, as @vcunat and @dezgeg. But I'd love to see how bad the damage is empirically, first. For example if fix patchShebangs (again!) first so bash shebanges would say unpatched (or use /usr/bin/env) rather than be the stdenv.shell defaultNativeBuildInput, we'd avoid that problem.

The one thing is actually I think we need to do allowedReferences on the other deps, rather than disallowedReferences on those deps, because of the case where something is a both a build-time and run-time dep in the native build.

I think this addresses that. We do "build time deps" - "runtime deps" with lib.subtractLists. The dev output thing could be an issue still.

Oh haha. I completely missed the lib.subtractLists call. Oops!

Then the question is whether this is blacklist approach better than the whitelist approach. My guess is what we really want is nix-level propagation logic and a whitelist based on that. (Note that bootstrap-tools would never be run-time dependency through propagatation.) In the meantime, the blacklist approach is more permissive in not disallowing things that should be propagated, so 👍 from me.

I really need to a get a hydra job up where I a) do strictDeps everywhere b) ensure all stdenv deps can be cross compiled too :). Time to write the RFC!

I support this idea, but it seems nix has problems with disallowed references and multiple outputs derivations: NixOS/nix#2310

I support this idea, but it seems nix has problems with disallowed references and multiple outputs derivations: NixOS/nix#2310

That only appears to happen with disallowedRequisites.

Ah sorry. So hopefully it can work :)

But I should probably remove the reference to disallowRequisites though just to be safe 😄

@GrahamcOfBorg eval

Woo!!!

If a derivation sets disallowedReferences, then it is clear what is not allowed. If mkDerivation sets it, then it can be quite surprising to get the message: output ... is not allowed to refer to the following paths:. What can we do to improve this?

This appears to be breaking kernel cross compilation (see #50915 (comment)), because the dev output refers to build perl, gcc and openssl. We could try to substitute these with host deps, but that really doesn't make sense.

If something depends on the cross compiled kernel's dev output, it is going to be cross compiled as well, and it is likely going to run the scripts in the dev output at build time. Therefore these scripts need to refer to build packages or they will probably fail.

This is not just true for the kernel; any cross compiled dev output is probably only going to be used on the build system, and therefore it doesn't make sense to disallow build references. Normally, this isn't a problem because the dev output is just headers that don't refer to anything. When there are scripts or makefiles that refer to other dependencies, this PR incorrectly breaks the build or we have to use hacks like putting /usr/bin/env in shebangs, like @Ericson2314 mentioned.

It seems to me that disallowing native build inputs in dev outputs is conceptually incorrect.

Agreed. Dev outputs are usually juts headers but there are enough corner cases to cause issues. I think the information from this is extremely valuable still - we just need to find a way to avoid the breakages. Anyway the cross-patch-shebangs branch has been reverted again! So we need to get that straightened out before we can do something like this either way. We will probably need to wait until something like NixOS/nix@3cd15c5 is widely available.

Sorry for any inconveniences! Reverted in 7eeb02d.