Subject: Re: [PATCH 0/4] build-system/cargo: Propagations across the crate closure.

From: Efraim Flashner <[email-masked]>
Date: Thu, 13 Aug 2020 12:48:43 +0300

On Thu, Jun 25, 2020 at 11:25:23PM +0200, Jakub Kądziołka wrote:
> Due to the unusual (for Guix) compilation model used by
> cargo-build-system, any phases or inputs added by a given library crate
> need to be duplicated in all its dependents. This patchstack attempts to
> solve this by allowing to propagate inputs, native-inputs and phases
> across cargo-inputs edges in the dependency graph.
> 
> Apart from the build system work itself, I have included samples of the
> cleanup they allow. Apart from being a good example, these are the
> changes I have used to test the feature.
> 
> Jakub Kądziołka (4):
>   build-system/cargo: Allow propagating inputs across CARGO-INPUTS edges
>   gnu: crates-io: Use propagated-inputs and propagated-native-inputs.
>   build-system/cargo: Add a propagated-phases argument.
>   gnu: crates-io: Use propagated-phases.
> 
>  gnu/packages/crates-io.scm  | 157 +++++++++++-------------------------
>  gnu/packages/rust-apps.scm  |   9 +--
>  gnu/packages/sequoia.scm    |   3 +-
>  guix/build-system/cargo.scm |  92 +++++++++++++++------
>  4 files changed, 120 insertions(+), 141 deletions(-)
> 
> -- 
> 2.26.2
> 

I'm going to respond here so the thoughts don't get lost. While it would
take care of some of the issues we have regarding adding regular inputs
or propagated-/native- inputs, I don't think this is the way we want to
go. If we can't figure out how to re-use build artifacts then I'd rather
copy the go-build-system and install the sources into the output and use
that as the input for the next package. That would give us the
build-graph which we really want.

-- 
Efraim Flashner   <[email-masked]>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted