[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#60847] [PATCH] Enable cross-compilation for the pyproject-build-sys
From: |
Maxim Cournoyer |
Subject: |
[bug#60847] [PATCH] Enable cross-compilation for the pyproject-build-system. |
Date: |
Sat, 11 Mar 2023 23:05:15 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Hi,
Ludovic Courtès <ludo@gnu.org> writes:
> 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.
OK.
>> 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.
When I don't understand something, I ask for an explanation. I'm happy
(and greatly value) that my correspondent has 15 years of experience
with Guile, but I'll still ask if something is unclear. I hope you
don't mind.
> [...]
>
>>> 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.
OK. I'll put this to the test, when I'm done with the current Ruby
rabbit-hole I've been pursuing. Thanks for the feedback!
--
Thanks,
Maxim
[bug#60847] [PATCH] Enable cross-compilation for the pyproject-build-system., Maxim Cournoyer, 2023/03/07
[bug#60847] [PATCH] Enable cross-compilation for the pyproject-build-system., Ludovic Courtès, 2023/03/10