From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:43735) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hN1v2-0008WS-37 for guix-patches@gnu.org; Sat, 04 May 2019 17:10:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hN1v0-0001EV-TG for guix-patches@gnu.org; Sat, 04 May 2019 17:10:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:38922) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hN1v0-0001EA-Pr for guix-patches@gnu.org; Sat, 04 May 2019 17:10:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hN1v0-0005Mv-K2 for guix-patches@gnu.org; Sat, 04 May 2019 17:10:02 -0400 Subject: [bug#35318] [PATCH] Update cargo-build-system to expand package inputs Resent-Message-ID: Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Ivan Petkov In-Reply-To: <20190504203123.2af2049f@scratchpost.org> Date: Sat, 4 May 2019 14:09:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0222B4A7-FFCD-42C3-B8EA-2CD933F1ADA4@gmail.com> References: <20190504203123.2af2049f@scratchpost.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Danny Milosavljevic Cc: 35318@debbugs.gnu.org, Chris Marusich Hi Danny, Thanks for the feedback! > On May 4, 2019, at 11:31 AM, Danny Milosavljevic = wrote: >=20 > @Ivan: >=20 > Thanks! I've tested it and it works. >=20 > But I don't understand yet why you change the role of "inputs" = compared > to how it is in the rest of Guix. >=20 > You have this: >=20 > +(define-public rust-proc-macro2 > + (package > [...] > + (build-system cargo-build-system) > + (native-inputs > + `(("rust-quote" ,rust-quote "src"))) > + (inputs > + `(("rust-unicode-xid" ,rust-unicode-xid "src"))) > [...] >=20 > Here, inputs refer to SOURCE parts of packages which are definitely = not > referred to at runtime. Does "guix gc --references = ...rust-proc-macro2..." > really refer to the source of rust-unicode-xid ? I checked, it = doesn't, > neither for the "src" derivation nor for the "out" derivation. >=20 > I think the general approach is good but I'm not certain that this = won't > break other parts of Guix. If it doesn't, fine. @Ludo: WDYT? To my understanding, Guix only needs the inputs and native-inputs to be = present in the store during build time, and only propagated-inputs need to be = present in the store during runtime. Since cargo crates don=E2=80=99t need the = source present at runtime, propagated-inputs seemed inappropriate to me. Pardon my ignorance on Guix, but what do you mean by =E2=80=9Cchanging = the role of inputs=E2=80=9D? Unless by this you mean changing the semantics of = =E2=80=9Cexpanding=E2=80=9D the inputs, then yes this is a departure from the existing usage. In my = mind, I want the Guix package definition to mirror the cargo one as it would = be a nightmare to maintain a list of the expanded transitive packages in each definition by hand. > Details: >=20 > A Rust crate has dependencies and dev-dependencies. >=20 > The crate needs the dev-dependencies only when building, not at = runtime. >=20 > Let "transitives of X" mean "X and transitives of immediate = dependencies of X and > transitives of immediate dev-dependencies of X", recursively. >=20 > The crate needs the source code of all its transitives to be available = when > building, but needs none of the source code at runtime. >=20 > A crate at run time only requires the immediate, if even that = (probably not!), > dependencies and none of the dev-dependencies, and not as source code. >=20 > So it's really not a propagated-input, although it kinda seems like a = weird > version of a propagated-input while building (something like a > native-propagated-input). >=20 > If this can't be generalized (and I'm not sure of that--Go has a = similar > static library-y view), we could also do those as (arguments ...) for = the > rust build system only--although not sure how to do the resolving of > transitives then. If this needs to be it=E2=80=99s own Guix concept, perhaps it would be = along the lines of propagated-native-inputs? I opted to make the cargo-build-system perform the work of the = transitive lookups since I wasn=E2=80=99t sure if this would truly be a generalized = feature=E2=80=A6 =E2=80=94Ivan=