guix-devel
[Top][All Lists]
Advanced

[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’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]