Hello Ludo,
On Tue, Oct 06, 2026 at 06:59:11PM +0200, Ludovic Courtès wrote:
>
> ;; "Target inputs" are packages that are built natively, but that are used
> ;; by target programs in a cross-compilation environment. Thus, they act
> ;; like 'inputs' as far as search paths are concerned. The only example of
> ;; that is the cross-libc: it is an input of 'cross-gcc', thus built
> ;; natively; yet, we want it to be considered as a target input for the
> ;; purposes of $CPATH, $LIBRARY_PATH, etc.
>
> So the fact that we have two search paths, not three, leads to this hack
> for cross-libc. I would expect it to be the only case where it matters.
Interesting, you mean if target (and not build) search paths would pick
out `cross-libc` from `build-inputs`, then `target-inputs` would be
unnecessary.
> That said, the cross-libc hack is not pretty, so perhaps we can do
> better.
How about only keeping the labels of `target-inputs`, and moving it to
the `search-path-specification` record type? In lieu of my suggested
`kind` field, build search paths have a `target-inputs` with (default)
value `#f`, the CPATH (etc.) host search path would use `'("cross-libc"
...)`, and other host search paths would use a `'()` value.
This way `bag` would have two types of inputs, and conceptually there
would still only be two types of search paths. I imagine migration to
this scheme would be complex and require a GCD. I hope my suggestion
is at least original. If you have past discussion on target inputs to
share, I would appreciate it.
> Whether it’s a sublist is not necessarily insightful.
>
> In practice, only compilers, linkers, and related tools may have a use
> for the non-native search path, for when they’re used as a cross
> toolchain.
>
> pkg-config is a bit of an outlier because it’s not designed to support
> cross-compilation, which is why we have this hack with the macro.
Yes in that case there is also `pkg-config-for-build`, but
`cmake-minimal-cross` and `cross-perl-extutils-pkgconfig` use comparable
hacks, and the "yes" sublist instances are candidates. What these hacks
avoid is dependent package cross builds where native search paths
override an identical search path. When that happens, some inputs would
need to be copied to native inputs, or a cross build phase which adds
inputs back to (or again overrides) the native search path is required.
I suggest a conflict error (**) instead of merging identical build and
host search paths, because the searched-for files could contain e.g.
references to shared libraries for build and host platform respectively.
It is too much too expect from build systems to sort out these files
themselves, that is why there is a separate PKG_CONFIG_FOR_BUILD, right?
I am not sure how to quantify how many duplicate native inputs or cross
build phases (a) host search paths (hack) could save for the "yes"
sublist instances, so if any helpful tools or scripts for such a task
come to mind, please let me know.
Cheers,
Herman
