Maxim Cournoyer writes: > Hi Christopher, > > Christopher Baines writes: > >> Maxim Cournoyer writes: >> >>> Hi Ludo! >>> >>> Ludovic Courtès writes: >>> >>>> Hello, >>>> >>>> Maxim Cournoyer skribis: >>>> >>>>> +++ b/guix/packages.scm >>>>> @@ -1864,28 +1864,30 @@ (define* (bag->derivation bag #:optional context) >>>> >>>> […] >>>> >>>>> + (let ((builder-name (procedure-name (bag-build bag)))) >>>>> + (if (or (bag-target bag) >>>>> + (eq? 'pyproject-build builder-name)) >>>>> + (bag->cross-derivation bag) >>>> >>>> This one part is a showstopper to me, for two reasons: >>>> >>>> 1. We cannot rely on ‘procedure-name’ (it’s a debugging aid and it’s >>>> not guaranteed to return something useful). >>>> >>>> 2. Special-casing build systems here is not okay: the bag and build >>>> system abstractions exist to maintain separation of concerns. >>>> >>>> I understand there’s an actual bug to fix and the desire to fix a more >>>> common issue, but I think this one approach is not the way forward. >>>> >>>> I hope that makes sense! >>> >>> I agree this is not "pretty", but it would be a "temporary" kludge until >>> all the build systems can be migrated (and the package adjusted for) the >>> "new" way, which is: native-inputs and inputs always co-exist, whether >>> the build is a native one or a cross one. >>> >>> In light of this, it seems OK to test the water with a not so >>> significant build system (only a handful of package relies on >>> pyproject-build-system thus far). When all the build systems will have >>> been migrated to the new way (a too big undertaking to be done in one >>> shot), this kludge can be removed. >>> >>> Otherwise, could you offer a concrete suggestion as the way forward? I >>> appreciate the "that's not the way", but stopping short of suggesting a >>> better alternative leaves me wanting more :-). >> >> I think it would be clearer to see other potential ways forward if the >> end goal was more clearly articulated. >> >> Guessing at that here from the changes proposed to guix/packages.scm, >> once all build systems are adjusted, cross derivations will be produced >> for all bags, regardless of whether there's a target. >> >> That doesn't make much sense to me. One explaination is that the current >> naming is confusing when thinking about this goal, so maybe >> bag->cross-derivation happens to do what you want it to do in all >> circumstances, even when target is #f? > > Thanks for tipping in. The end goal is to avoid loosing the information > of which inputs are native (build inputs) vs regular in the bag, and yes > bag->cross-derivation allows that. It appears to me the distinction in > the bag representations (native vs cross) was originally perceived > useful as some kind of optimization (there's less variables to worry > about, and we can squash the inputs/search-paths together, since they're > all native anyway), but this information (currently discarded) ends up > being very useful even on the build side (to wrap only the target > inputs, say, and not all the native/build inputs). > > So yes, the change long term would be to integrate the > bag->cross-derivation logic into bag->derivation, at which point it > would be unified for any type of build (the bag representation would be > shared between native and cross builds). Thanks for the explanation, so maybe an alternative to trying to get bag->derivation to function differently for different build systems would be to push combining the inputs down in to each build system. Take the gnu-build-system as an example, gnu-build in (guix build-system gnu) would be changed to take multiple lists of inputs, rather than a single list. It can then combine the lists of inputs as is done in bag->derivation, to avoid affecting any packages. While this does require changing all the build systems, I think it's a bit more forward thinking compared to trying to add a kludge in to bag->derivation, since hopefully the change there can be the longer term one. Does that make sense?