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

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Ludovic!

Ludovic Courtès <ludo@gnu.org> writes:

> 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.

Oops, it's #60847 (https://issues.guix.gnu.org/60847).

>> 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.

Separate builders (like is currently done) also have another plus, which
is that bugs in the cross-compilation builder can be fixed separately
without impacting the native builder.

> 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.

Yes; that's why starting with a builder that affects little packages
(pyproject-build-system has like 100 packages using it) gives us a nice
testing ground to validate the idea is sound.

-- 
Thanks,
Maxim