[bug#60847] [PATCH] Enable cross-compilation for the pyproject-build-system.

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

Hi Ludo!

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

> Hello,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> 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 :-).

-- 
Thanks,
Maxim