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

Previous Next

Full log

Message #50 received at 60847 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Josselin Poiret <dev <at> jpoiret.xyz>, Christopher Baines <mail <at> cbaines.net>,
 Simon Tournier <zimon.toutoune <at> gmail.com>, Mathieu Othacehe <othacehe <at> gnu.org>,
 60847 <at> debbugs.gnu.org, Tobias Geerinckx-Rice <me <at> tobias.gr>,
 Lars-Dominik Braun <lars <at> 6xq.net>, Ricardo Wurmus <rekado <at> elephly.net>,
 jgart <jgart <at> dismail.de>
Subject: Re: bug#60847: [PATCH] Enable cross-compilation for the
 pyproject-build-system.
Date: Fri, 10 Mar 2023 09:57:11 +0100

Hi Maxim,

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

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Hello,
>>
>> Maxim Cournoyer <maxim.cournoyer <at> 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

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

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

Again, I’m not sure about the “new way”.  I’m sorry I lack the bandwidth
to review this quickly, especially a wide-ranging change like
inputs/native-inputs.

(Just yesterday I was fixing cross-compilation issues on ‘core-updates’;
that gives a lot of insight as to how native-inputs/inputs play out in
practice.)

[...]

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

Yup, I’m sorry I don’t have any suggestions!  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.

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.