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

Previous Next

Full log

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
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: Tue, 07 Mar 2023 09:08:10 -0500

Hi Ludo!

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

Previous Next

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