guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Christopher Baines
Subject: [bug#60847] [PATCH] Enable cross-compilation for the pyproject-build-system.
Date: Tue, 07 Mar 2023 15:05:47 +0000
User-agent: mu4e 1.8.13; emacs 28.2

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> 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 :-).

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?

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]