From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 07 14:48:07 2023 Received: (at 60847) by debbugs.gnu.org; 7 Mar 2023 19:48:07 +0000 Received: from localhost ([127.0.0.1]:47230 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pZdI6-0007w9-Rn for submit@debbugs.gnu.org; Tue, 07 Mar 2023 14:48:07 -0500 Received: from mira.cbaines.net ([212.71.252.8]:42350) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pZdI4-0007vm-Ps for 60847@debbugs.gnu.org; Tue, 07 Mar 2023 14:48:05 -0500 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:3a91:a0a4:ecee:f157]) by mira.cbaines.net (Postfix) with ESMTPSA id B6BAB16DAE; Tue, 7 Mar 2023 19:48:03 +0000 (GMT) Received: from felis (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id d3a2670b; Tue, 7 Mar 2023 19:48:03 +0000 (UTC) References: <20230123133217.318-1-maxim.cournoyer@gmail.com> <20230123133217.318-2-maxim.cournoyer@gmail.com> <87zg8p7qvw.fsf_-_@gnu.org> <87jzzsy7qt.fsf@gmail.com> <87jzzsr3tx.fsf@cbaines.net> <87a60owfi8.fsf@gmail.com> User-agent: mu4e 1.8.13; emacs 28.2 From: Christopher Baines To: Maxim Cournoyer Subject: Re: bug#60847: [PATCH] Enable cross-compilation for the pyproject-build-system. Date: Tue, 07 Mar 2023 19:26:47 +0000 In-reply-to: <87a60owfi8.fsf@gmail.com> Message-ID: <87fsagqr67.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 60847 Cc: 60847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Maxim Cournoyer writes: > Hi Christopher, > > Christopher Baines writes: > >> Maxim Cournoyer writes: >> >>> Hi Ludo! >>> >>> Ludovic Court=C3=A8s writes: >>> >>>> Hello, >>>> >>>> Maxim Cournoyer skribis: >>>> >>>>> +++ b/guix/packages.scm >>>>> @@ -1864,28 +1864,30 @@ (define* (bag->derivation bag #:optional cont= ext) >>>> >>>> [=E2=80=A6] >>>> >>>>> + (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 =E2=80=98procedure-name=E2=80=99 (it=E2=80=99s = a debugging aid and it=E2=80=99s >>>> 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=E2=80=99s an actual bug to fix and the desire to fi= x 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? > > Thanks for tipping in. The end goal is to avoid loosing the information > of which inputs are native (build inputs) vs regular in the bag, and yes > bag->cross-derivation allows that. It appears to me the distinction in > the bag representations (native vs cross) was originally perceived > useful as some kind of optimization (there's less variables to worry > about, and we can squash the inputs/search-paths together, since they're > all native anyway), but this information (currently discarded) ends up > being very useful even on the build side (to wrap only the target > inputs, say, and not all the native/build inputs). > > So yes, the change long term would be to integrate the > bag->cross-derivation logic into bag->derivation, at which point it > would be unified for any type of build (the bag representation would be > shared between native and cross builds). Thanks for the explanation, so maybe an alternative to trying to get bag->derivation to function differently for different build systems would be to push combining the inputs down in to each build system. Take the gnu-build-system as an example, gnu-build in (guix build-system gnu) would be changed to take multiple lists of inputs, rather than a single list. It can then combine the lists of inputs as is done in bag->derivation, to avoid affecting any packages. While this does require changing all the build systems, I think it's a bit more forward thinking compared to trying to add a kludge in to bag->derivation, since hopefully the change there can be the longer term one. Does that make sense? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmQHlPFfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XcLrBAAoFT5BfSDlpaQqOx1NctpOIqTrX48SG0l RS1P8YKtucY1yqYWDS9U9IB640fhfjLKP0rYtXcucFHGkMvqOgVnakKf2Dl9KDwu j51oNMSzMkw44l4yOvh0hc7L10Crb77NymS/n+JXQnnRDbqDnX+X6IEkZjvzsSaW +aDUw3b+Zf75IKcrrCnoTJRW8cF01M80lMC1oDR0zJg21ctmSU9NlVO1WRIik2wg vCw7Z8Y6SfivqDXhK8OfogKVFqHUbveRHZJ1BQO115/YrUqN4gO0oCX9XUPVWyJ1 0r0IqIsPaaziw4TwmWS9kmXfJnqKwwYmSwVbXPRpGVbKm08uEoGftXI2IcFKKXK8 9Lwk79lxYG3mzsOMN49r4Zh7HrY0p3aFbf9IojxZWS1SMf9Ffw3xC4jyTN49lAdD r8rNFjXpkaIUN9hYfiWWW6/s4wlrMIi1FPnGCgZVh4erHNfLNpJi5cr2NuNnIV3A jDt/lQR4wowbeKrh2Fm0WfJj/nEw3wEUOvacwj0sRALtXNrg2xUs2LjluWPtvjNX OYMQ1TMpsWy2N2nUJhXvB9Mgwj0c1fSvXtxflY2RLo8XF0VqHv/tQcmE4tdlwFof 06NbGJVVOuv9PYtbaQtxCK2cZGDI5rDW+cnJr2Tu257ItcUndcbJZhZgkcJeOAbb F2kWX7NBdgE= =N7ZY -----END PGP SIGNATURE----- --=-=-=--