Re: Uniformly treating native-inputs in native or cross build contexts

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> In #60857, I've unified the cross/standard builders for the
> pyproject-build-system; even their bags representation are now
> shared. It enables fixing things such as #25235.

What’s the number again?  <https://issues.guix.gnu.org/60857> seems to
be unrelated.

> Going forward, I think it'd be beneficial to apply the same strategy to
> other build systems, for consistency and to allow filtering purely build
> inputs from the inputs captured in the wrap phases.
>
> Thoughts, concerns?

I don’t recall the detailed reasoning for doing it this way, but I think
it was roughly along these lines: when doing a native build, there’s no
reason to distinguish between “native inputs” and “inputs” because all
the inputs are native.  When computing search paths or iterating over
input directories to strip, you’d just iterate over #:inputs, period.

In <https://issues.guix.gnu.org/25235>, we’re interested in giving
‘native-inputs’ a different meaning, that of build dependencies.
Packages listed in ‘native-inputs’ are indeed usually build-only
dependencies.  Yet, we’re trying to stretch the definition of
‘native-inputs’ to something like ‘build-dependencies’, which leads to
different needs.

Independently of this consideration, any change in this area can be
tricky to test: all the build systems and packages may be affected, both
with native builds and cross builds.

I’m not saying things should be set in stone but rather that one should
be prepared for long experimentation times and coming up with a
deprecation schedule if it turns out that the changes are introduce some
incompatibility.

My thoughts as an old guy.  :-)

Ludo’.