Hi, On Tue, Oct 06, 2026 at 06:59:11PM +0200, Ludovic Courtès wrote: > > 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. > > That said, the cross-libc hack is not pretty, so perhaps we can do > better.
Correct me if I am wrong, I took this to mean that because you decided to have two instead of three search paths fields, the `bag` record needs a `target-inputs` field to put cross-libc into. That extra field is part of the cross-libc hack. On Wed, Oct 14, 2026 at 04:52:02PM +0200, Ludovic Courtès wrote: > > Herman Rimm <[email protected]> skribis: > > > This way `bag` would have two types of inputs, and conceptually there > > would still only be two types of search paths. > > So nothing would change?… Sorry, I’m trying to wrap my head around it > but I’m not sure I follow. > > Could you clarify the problem we are trying to solve? I propose to remove the `target-inputs` field from the `bag` record type and add it to the `search-path-specification` record type instead. I guess the total amount of fields between these record types does not change, but for `search-path-specification` a `target-inputs` field can also indicate that it is a build/native search path when it is #f, so then the `package` record type would not need `native-search-paths`. Although, moving `target-inputs` would complicate the definition of `%build-target-inputs` in `gnu-cross-build`, etc.. Cheers, Herman
