| Message ID | 20200625212523.25016-1-kuba@kadziolka.net |
|---|---|
| Headers | show |
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.