From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ivan Petkov Subject: Re: Current state of cargo-build-system Date: Sun, 27 Jan 2019 15:13:24 -0800 Message-ID: References: <0FA91CF1-5040-4175-9347-7FEF74CCD725@gmail.com> <20190123181000.6c5fc532@scratchpost.org> <2E175E19-40C4-4954-A282-EE31C77D7A5D@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:49718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gntcV-0004VF-Tu for guix-devel@gnu.org; Sun, 27 Jan 2019 18:13:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gntcU-0007FU-6y for guix-devel@gnu.org; Sun, 27 Jan 2019 18:13:43 -0500 Received: from mail-pl1-x62b.google.com ([2607:f8b0:4864:20::62b]:40197) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gntcU-00079D-0j for guix-devel@gnu.org; Sun, 27 Jan 2019 18:13:42 -0500 Received: by mail-pl1-x62b.google.com with SMTP id u18so6903547plq.7 for ; Sun, 27 Jan 2019 15:13:27 -0800 (PST) In-Reply-To: <2E175E19-40C4-4954-A282-EE31C77D7A5D@gmail.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel Answering my own question after digging through the guix source, maybe = someone can correct me if I=E2=80=99ve gotten things wrong! > On Jan 25, 2019, at 3:57 PM, Ivan Petkov = wrote: >=20 > However, it appears that guix still insists on building the entire = package even > if we only depend on the "src" output. Is it possible to lazily build = packages > based on the type of dependency? Is this something the build system = can finagle, > or is this an inherent limitation to guix? So it appears that guix takes package definitions and feeds them to = their respective build system, which then get lowered to a bag (a more = low-level representation of a package). The bag is then built as the actual = derivation. Thus it is possible for the build system to do any kind of preprocessing = of the dependency closure or even produce dynamic/hidden packages if neccessary = (but is this discouraged?). It also appears that guix expects to build the package entirely and it = allows the build system to split up the result into various outputs, but there = isn't a notion of lazily building out only the required outputs (I suppose the = real solution to this would be to break up the package definition in the = appropriate way to support this). I have some ideas on how to resolve our cargo woes, namely by = introducing crate-source-only packages that don't actually get built and substitute = those for any potential cycles. I'd like to make imports and maintenance of = package definitions as simple as possible, so I'd like to explore making the = build system a bit more clever in handling this. Will do some more prototyping on my own and report back! --Ivan