Hi, Maxim Cournoyer <maxim.courno...@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’.