propagatedNativeBuildInputs does not propagate

[FRidh]

Issue description

If I add e.g. a hook in propagatedNativeBuildInputs, then I expect it to be executed by reverse dependencies. This is not the case. Putting it in propagatedBuildInputs solves the issue, but that should break cross-compilation.

Related issue #37991

Steps to reproduce

Technical details

Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.

cc @Ericson2314

[Ericson2314]

propogated native build inputs only works if your dependency is in buildinputs, depsHostHost or depTargetTarget. Otherwise we have two -1 offset which sum to a negative -2 offset so the transitive dependency is "out of bounds".

[Ericson2314]

propagatedBuildInputs looks correct to me because xfce4-dev-tools is a nativeBuildInput. propagatedBuildInputs . nativeBuildInputs = nativeBuildInput so to speak. My nativeBuildInput's run time is my build time.

[roberth]

I also ran into this and I can confirm that propagatedBuildInputs works for my use case in hercules-ci-effects.
It also works with strictDeps = true; and the original issue has been resolved in 6b72364.

However, the documentation has the following example and says

X <--propagatedNativeBuildInputs-- Y <--nativeBuildInputs-- Z

If instead, package Z has nativeBuildInputs = [Y], then Z will be built as if it included X in the depsBuildBuild of package Z, because of the sum of the two -1 host offsets.

and

depsBuildBuild [...] Since these packages are able to be run at build-time, they are always added to the PATH

So I inferred that it would work, which it doesn't.

@Ericson2314 Did I misunderstand or is the documentation incorrect?

Perhaps this use case should be documented as an example of propagatedBuildInputs in the manual. Both my use case and the original one involve a package that bundles nativeBuildInputs by propagating them and both also define a setup hook script (although the setup script is not essential, it is does seem to form a pattern).

[roberth]

Maybe my proposal in #28327 (comment) helps here. Among other things I propose renaming buildInputs -> components and:

I also expect components to help with the intuition around propagation and setup hooks, the thought being: component builds are like my own build, so their propagation and setup hooks behave like my own.

[roberth]

Needs at least docs.