Remember the difference between inputs and propagated inputs:
they're the same, but when you create a profile, inputs are not
part of the
profile (so they need a direct store reference, such as RPATH or
a wrapper), whereas propagated inputs are part of the profile,
so an
environment variable allows to find them.
Thank you for patiently explaining, I think I am starting to
understand now, but please correct me if I am still wrong.
So there is package build-time, profile build-time, and run-time.
Wrappers should be used to set environment variables when the
value can be determined at package build-time, such as absolute
paths to inputs.
Search paths should be used to set environment variables when the
value will be determined at profile build-time, such as relative
paths to either propagated-inputs or packages that also installed
in the same profile, but not listed explicitly as
propagated-inputs to the package declaring the search paths.
I am still a little unclear about the difference between
search-paths and native-search-paths, though. If not
cross-compiling then they act the same? If you are
cross-compiling, though, then it only finds packages that are
listed as native-inputs to the package declaring the search paths?
Native-inputs are not normally installed in a profile, though,
correct? Does that mean native-search-paths will only be found
when using a development shell when cross-compiling?
I guess I do not properly understand cross-compiling. So when
cross-compiling, there is a package build-time, where you are
building packages for a target architecture on a host machine,
profile build-time, where you are building a profile on the
target, and run-time, when you are running on the target? If
search-paths and native-search-paths are determined at profile
build-time, how do they behave differently on the target machine?