Thanks so much!!

Does this actually work? I don't think either environment.systemPackages or nix-env -i will follow propagated build inputs.

I think you should be just able to do:

ln -s ${cc.man} $man

See #44558.

I'm sorry. I might has improperly tested that. (Worse, I have some dejavu as if I made the same mistake before.)

In a post-strictDeps world, it would actually make sense to make propagatedBuildInputsdo that, but there's nothing wrong with the symlink thing so let's just do that.

@Ericson2314 Nah, don't mind, breaking things is half the fun after all.

#44558 needs some testing love on Darwin, though.

But if it's not, then I feel like propagated-user-env-packages makes more sense there semantically

I agree, I also thought propagated-user-env-packages would work. But I guess it's only looked in the main output and not in man or the others.

In a post-strictDeps world, it would actually make sense to make propagatedBuildInputsdo that, but there's nothing wrong with the symlink thing so let's just do that.

Why? propagatedBuildInputs are only intended for building stuff that depends on the package. In multiple-outputs packages they aren't even visible at runtime, because the propagated-build-inputs file only exists in the dev output. Of course this strictDeps thing will never, ever be going to happen for native compilation so it's a moot point, but anyway...

You said it yourself; it isn't used on things people want to install anyways. propagatedBuildInputs, rightly used, is basically only for libraries that rely on other libraries. It wouldn't be used by things people install anyways, even if it weren't for multiple outputs.

OTOH, if you manually install a dev output, I don't see why you shouldn't get the propagated deps too. Otherwise, the headers are useless.

Manually installing .dev outputs isn't going to work anyway because setup hooks won't be run. It's just not supported (currently).