Hi Ludovic! Ludovic Courtès <l...@gnu.org> writes:
> 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. 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