guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Current state of cargo-build-system


From: Danny Milosavljevic
Subject: Re: Current state of cargo-build-system
Date: Wed, 23 Jan 2019 18:10:00 +0100

Hi Ivan,

On Sun, 20 Jan 2019 16:11:58 -0800
Ivan Petkov <address@hidden> wrote:

> Are there any philosophical or technical blockers that preclude pulling in
> packages from crates.io, 

Cycles.  Also, often Cargo.lock specifies exact versions of dependencies (in
programs, at least).

>or is it just a matter of chipping away at the problem?

Pretty much.

Back in the day, Rust was in a state of flux.  Now, I think they finally
committed to not changing the floor from under us while we are walking on it
(the "edition" key in Cargo.toml is used to select the Rust version to target).
So it makes sense to try again now.

First, we'd have to find out what kind of things Cargo can build and how to
detect it.

I've used Rust to write a tiny operating system - and there, I use a hybrid
configuration for the same package: it's both a library and a program.
For that, I used a directory with files src/lib.rs and src/main.rs in it, but
I'm not sure whether that's set in stone or just what I came up with / the
tutorial says.

See also <https://github.com/rust-lang-nursery/api-guidelines/issues/167>.

After that, we can decide whether to compile libraries or just ship them as
source (right now, we do the latter pretty often - almost everything in Guix
Rust library packages ends up in the "src" output).

Getting the unit tests to run often requires breaking many cycles, so maybe
skip that at first.

I've attached my ancient attempt to package some crates--but I think ng0's
patchset is nicer than that.

Attachment: crates.scm
Description: Text Data

Attachment: pgpktYKGVmr6B.pgp
Description: OpenPGP digital signature


reply via email to

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