| Message ID | 20200625212523.25016-1-kuba@kadziolka.net |
|---|---|
| Headers | show |
| Series | build-system/cargo: Propagations across the crate closure. | expand |
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.
On Thu, Aug 13, 2020 at 12:48:43PM +0300, Efraim Flashner wrote: > 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. Note that this wouldn't solve all the issues, we would still need an equivalent for propagated phases, to set any environment variables necessary. Moreover, note that the reason the current system was introduced in the first place was to avoid the quadratic builds. I suppose this is less of an issue in go-build-system due to the order-of-magnitude difference in compiler speed on typical source code. As for re-using build artifacts, once we figure out how to do it, we can always revert this patch, together with the one that originally added cargo-inputs. I don't think it's going to be any time soon, though, as upstream doesn't support this style of building. Regards, Jakub Kądziołka
On Thu, Aug 13, 2020 at 06:16:38PM +0200, Jakub Kądziołka wrote: > Moreover, note that the reason the current system was introduced in the > first place was to avoid the quadratic builds. I suppose this is less of > an issue in go-build-system due to the order-of-magnitude difference in > compiler speed on typical source code. Right. The go-build-system is far from optimally efficient but, in practice, it's not too slow. I haven't counted but I figure that Rust dependency graphs are an order of magnitude larger.