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

["Ludovic Courtès" <ludo@gnu.org>]

Hi Maxim,

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

[...]

>>>>> +  (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
>>
>> To make sure there’s no misunderstanding, I think that’s not okay even
>> as a “temporary kludge” (I’m not against temporary kludges in general,
>> I’ve done my share of that ;-), but this would be way too brittle.)
>
> "way too brittle" is a strong warning :-).

It is; I’m objecting to this change.

> I don't understand what is
> so brittle about it?  It's not like we change the build system names
> often.

I have little to add to what I wrote above: procedure names don’t mean
anything, especially with higher-order functions, and separation of
concerns is an important design principle.

I’m speaking with 15+ years of experience with Guile; I don’t mind being
challenged, it’s healthy, but I think we also need to recognize the
expertise of each other and encounter each other halfway.

[...]

>> Perhaps one suggestion would be: start the native-inputs/inputs change
>> on a new branch, for all the build systems (or at least the main
>> ones), and then try to build the ‘core’ subset (which includes
>> cross-compilation) to get an idea of the kind of code simplification
>> opportunities as well as issues that arise.  I feel like it’s hard to
>> anticipate the impact of such a change without actually trying.
>
> I can do this; the exercise would be similar to what I've done for
> pyproject-build-system, where I was able to build complex packages (both
> natively and cross-compiled) with the new same-bag representation
> change, but to a larger scale.  It's more work, which is why I would
> have preferred to contain its scope to get started, but the changes were
> easy, IIRC.

Yes, I agree it’s more work, but it’s dissimilar in that you’ll be
confronted with tons of weird cases, some of which we can already
anticipate, but probably others we’ll probably be surprised to discover.

> Basically, it forces us to review all the (assoc-ref inputs
> "package-name") or (search-input-file inputs "file") procedure calls and
> remove the assumption that native-inputs are also inputs for native
> builds (that'll fix multiple cross-compilation bugs at the same time, so
> it's a good thing to do anyway).

I do hope it’ll be this simple, but I just can’t tell.

Thank you,
Ludo’.