Hi Guix,
If I correctly understand `bag->derivation` and `bag->cross-derivation`
in `(guix packages)`, then (via `package->bag`) the kinds of package
inputs (excluding propagated) included in search paths are as follows:
s-path|native|normal
build | |
------|------|------
normal|native|
|normal|
------|------|------
cross |native|normal
| |*
* Overriden by an identical native search path.
Note the empty top-right quadrant; in this case the `set-paths` phase
runs with `#:native-search-paths '() #:search-paths native-search-paths`
arguments. But the `pkg-config` macro for example, effectively defines
a package where this quadrant is replaced by the top left one:
s-path|PKG_CONFIG_PATH
build |
------|------
normal|native
|normal
------|------
cross |normal
|
Note how for cross builds there is no longer a (`%pkg-config`) native
search path which overrides the identical search path, which means fewer
native inputs and cross build phases for `pkg-config` dependents. This
behavior could be reified into another kind of search path:
s-path|build |target|host
build | | |
------|------|------|------
normal|native| |native
|normal| |normal
------|------|------|------
cross |native|normal|normal
|** |* |***
* Overriden by an identical build search path.
** Conflict error with an identical host search path.
*** Still including bag target inputs.
Before considering implementation, I think one should have in mind the
package (procedure) definitions where `search-paths` is not a sublist of
`native-search-paths`:
`search-paths` sublist
`libvisual` yes
`cross-gcc` no
`make-mingw-w64/implementation` no
`agda` yes
`cmake-minimal-cross` no*
`gawk` no
`make-clang-toolchain` yes**
`rocm-toolchain` yes**
`cross-perl-extutils-pkgconfig` no*
`libxml2` yes
`package-with-relocatable-glibc` no
`tcl-tls` no
`gtk+-2` yes
`gtk+` no
`gtk` yes
`glib` yes
`gobject-introspection-minimal` yes
`cross-pkgconfig` no*
`make-gcc-toolchain` no
* `search-paths` is the inherited `native-search-paths` and
`native-search-paths` is `'()`.
** `search-paths` is non-empty.
I would not add a `host-search-paths` field to `<package>`, because only
the three "no*" packages would make use of the field. I would rather
exchange the `native-search-paths` field of `<package>` for a `kind` (or
`type`) `<search-paths>` field (with a `'native` default value), because
I believe (at least) 11 "no" instances is also too few to justify a
`search-paths` field distinct from `native-search-paths`. Also, in
principle packages should agree on whether a given search path is for
finding architecture-invariant (build platform) files, or for finding
host and target platform files.
As a less drastic option, one could add a thunked `#:build-search-paths`
argument to override (and unset) `native-search-paths` when `(%current-
target-system)` is true. It would be more generic and limited than the
`#:cmake` argument, if handled in both the `bag->derivation` and
`bag->cross-derivation` procedures.
Regardless, I believe host search paths would be more consise than a
"cross" package variant together with a macro or thunked (`#:cmake`)
argument, but would also require additions to `evaluate-search-paths`
or related procedures.
By the way, you may have noticed that `gtk+` is a "no" while the
adjacent GTK packages are "yes". I think in this case `search-paths`
should also be sublist of `native-search-paths`. (See also commits
4828ff91ffa937fa6cb1618fcab550c137e60f15 and
e0fc4c1fa7cb39bd27d4f148ca6f35a89db88c40.)
Regarding documentation, I think most contributors interested in cross
compilation first learn how inputs differ from native inputs before
encountering `search-paths`. Therefore, based on the `search-paths`
name I would assume it is analogous to the `inputs` field. In that case
the following passage in the manual:
> As for inputs, the distinction between ‘native-search-paths’
and ‘search-paths’ only matters when cross-compiling. In a
cross-compilation context, ‘native-search-paths’ applies
exclusively to native inputs whereas ‘search-paths’ applies
only to host inputs.
would make me think search paths work as follows:
s-path|native|normal
build | |
------|------|------
normal|native|native
|normal|normal
------|------|------
cross |native|normal
| |*
* Appended to identical native search path.
That assumption justifies the top-right quadrant, and then makes it seem
like the first sentence of the passage is clarifying that the top-left
quadrant does not merely contain native inputs. I think the build (or
host) and target (or cross?) names for search paths would have prevented
this misconception from forming, for me at least.
WDYT? I would also appreciate editorial feedback.
Cheers,
Herman
