GNU bug report logs - #35318
[PATCH] Update cargo-build-system to expand package inputs

Previous Next

Full log

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

From: Ivan Petkov <ivanppetkov <at> gmail.com>
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: ludo <at> gnu.org, 35318 <at> debbugs.gnu.org, Chris Marusich <cmmarusich <at> gmail.com>
Subject: Re: [PATCH] Update cargo-build-system to expand package inputs
Date: Sat, 4 May 2019 14:09:44 -0700

Hi Danny,

Thanks for the feedback!

> On May 4, 2019, at 11:31 AM, Danny Milosavljevic <dannym <at> scratchpost.org> wrote:
> 
> @Ivan:
> 
> Thanks!  I've tested it and it works.
> 
> But I don't understand yet why you change the role of "inputs" compared
> to how it is in the rest of Guix.
> 
> You have this:
> 
> +(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")))
> [...]
> 
> 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.
> 
> 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’t need the source present
at runtime, propagated-inputs seemed inappropriate to me.

Pardon my ignorance on Guix, but what do you mean by “changing the role
of inputs”? Unless by this you mean changing the semantics of “expanding”
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:
> 
> A Rust crate has dependencies and dev-dependencies.
> 
> The crate needs the dev-dependencies only when building, not at runtime.
> 
> Let "transitives of X" mean "X and transitives of immediate dependencies of X and
> transitives of immediate dev-dependencies of X", recursively.
> 
> The crate needs the source code of all its transitives to be available when
> building, but needs none of the source code at runtime.
> 
> 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.
> 
> 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).
> 
> 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’s 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’t sure if this would truly be a generalized feature…

—Ivan

Previous Next

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