[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Overhauling the cargo-build-system
From: |
Ludovic Courtès |
Subject: |
Re: Overhauling the cargo-build-system |
Date: |
Sat, 16 Nov 2019 22:33:32 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Hello!
Martin Becze <address@hidden> skribis:
> Sorry for digging up and old issue, but i just saw commit
> 86e443c71d4d19e6f80cad9ca15b9c3a301c738c
>
>> It makes for a very large package definition, but we
> wouldn't have to ensure thousands of other rust libraries built so we
>
> The whole point of package management is that you can use module
> building blocks. By having to specify the sub-dependencies in a top
> level definition kinda breaks the whole modular thing. In commit
> 86e443c71d4d19e6f80cad9ca15b9c3a301c738c all the inputs got removed for
> all the libraries. So if I'm trying to use guix as package manager for a
> rust project and I want to use one of the rust libraries in
> crates-io.scm, how am i suppose to do this? I can't just include it as
> an input to my project because now I have to look up all of it
> dependencies as well?
I agree that removing all the dependencies from Rust packages feels
wrong.
What I would have liked is to somehow replace the #:cargo-inputs
argument (which is build-system-specific and thus “opaque”) with regular
‘native-inputs’ or ‘inputs’ field.
I know it’s not that easy with Rust and Cargo, I just never manage to
fully grasp why :-), but at least that should be our horizon IMO.
WDYT, Efraim, Martin, and other Rusty people? :-)
Thanks,
Ludo’.