From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 10 09:13:21 2023 Received: (at 60847) by debbugs.gnu.org; 10 Mar 2023 14:13:21 +0000 Received: from localhost ([127.0.0.1]:54130 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1padUn-0002vu-8h for submit@debbugs.gnu.org; Fri, 10 Mar 2023 09:13:21 -0500 Received: from mail-qv1-f50.google.com ([209.85.219.50]:42512) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1padUl-0002ve-QI for 60847@debbugs.gnu.org; Fri, 10 Mar 2023 09:13:20 -0500 Received: by mail-qv1-f50.google.com with SMTP id ne1so3649281qvb.9 for <60847@debbugs.gnu.org>; Fri, 10 Mar 2023 06:13:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678457594; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=jv1DEXKfrqC0RJs672G836Arnhk8t464a7KRZP90oj8=; b=jTu0ntejiVo/kq4dbAjEgU7ol3VsH+Jv8GwaDDNH/SizN+K082jNXo2ebOKXdQgRJ0 QwuRAV4mTihfV4w4YMr/w500eOBq2685Gh31STIsF2nqMzgMbSeRIa4WHMqpPYz25aCR GFy3bYWYUj0le0jTvOwI9vktLcAiEsr/1Ep6q3/DNIDI3i21yqcqUvQvbHFChTDvlIpZ eloQ9AvnlbuxDsywATXMZGatHOyR4dHk8ZjKqBBcaDt1BxQB/ydYqQxMMBGfIkVlXpZK tMHARpVrFuawoR9KoYNkCFWaZfmV4/2kyFY044iT4GikCD60wCmEiLLcnHaCtmV3p6uw McvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678457594; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=jv1DEXKfrqC0RJs672G836Arnhk8t464a7KRZP90oj8=; b=78O3TJT/dQG3EbQBEdVHQq7dzJBOzkgKQb9XAgeQnTV2Arne9e0AFsevs3hMpBvcFK 2MjF/+rNscGCClyS1jP/oChXDMVRxY9c9GNfdL9M3k3/4o9axeCFc8FjjyA4ecpuw4xx ixs4/FXJp/bBCNiREn7D+MjH29Mb6BWc2+WYBXxWDFviQ+YLsFeUxNGFPEx8We8SHNTR 87lWgi0gyKOPXmGGwkHr+SKP7urwRRMZJkwgSrqecQfpOrEPiGwIbv+Zc3vyG6j9H4ua Cm7e53D1GVoDAZSF7IXv9yvhyxUF6R9+hUne10lLPt/0Os3RCeNdUKJqVmn5nAuU3ztv H5vg== X-Gm-Message-State: AO0yUKXfnEPMEWghOLEn37HXIExa52BCEPCgBlI/0IA+TiYCBQVLDfMP UnPW+NnJw1CPJDAVWcnBacAJjhRnsEeFmA== X-Google-Smtp-Source: AK7set8S9AVk33sHhI2LCilj+y+SvYNirjzwWUsh08FTXeA/dXN2+Qac7qQsJ2BmMOJBa54C5hsriA== X-Received: by 2002:a05:6214:ca8:b0:56e:c238:b719 with SMTP id s8-20020a0562140ca800b0056ec238b719mr47681018qvs.2.1678457593928; Fri, 10 Mar 2023 06:13:13 -0800 (PST) Received: from hurd ([2607:fad8:4:3::1000]) by smtp.gmail.com with ESMTPSA id a10-20020ae9e80a000000b00742743dba2asm1409828qkg.39.2023.03.10.06.13.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Mar 2023 06:13:13 -0800 (PST) From: Maxim Cournoyer To: Christopher Baines Subject: Re: bug#60847: [PATCH] Enable cross-compilation for the pyproject-build-system. 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> <87fsagqr67.fsf@cbaines.net> Date: Fri, 10 Mar 2023 09:13:12 -0500 In-Reply-To: <87fsagqr67.fsf@cbaines.net> (Christopher Baines's message of "Tue, 07 Mar 2023 19:26:47 +0000") Message-ID: <87zg8kr8xz.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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 (-) Hello Christopher, Christopher Baines writes: [...] >> 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. I'll see if I have a good enough understanding of the code to make sense of your suggestion. I'll definitely try it! Thanks for suggesting. -- Thanks, Maxim