Uniformly treating native-inputs in native or cross build contexts

Uniformly treating native-inputs in native or cross build contexts

[Maxim Cournoyer]

Hello Guix,

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.

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?

-- 
Thanks,
Maxim

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

[Ludovic Courtès]

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

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

[Maxim Cournoyer]

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