Re: 77 Rust Crates, fluid, roboto-font, libpsyc rust bindings

[ng0]

Danny Milosavljevic <address@hidden> writes:

> Hi ng0,
>
>> > For those I checked (like rust-openssl-sys) left me in confusion. Does our 
>> > cargo build-system just build nothing?
>
> Most Rust libraries are installed as source code (similar to C++ templates 
> which are also installed as source code).

Okay, I'm totally new to Rust, the developers at my side might've
told me before but I forgot about it I guess.

> The current Guix master cargo build system doesn't build anything.

Ah!

> On the other hand, my WIP v2 build system does build the libraries. But 
> that's not because it installs the stuff it built (it shouldn't - it should 
> install the source code), it's just to make it easily possible to find out 
> what dependencies are missing and whether it's the correct version of the 
> library (e.g. working in Rust stable). Is builds in the "build" phase AND in 
> the "check" phase in order to find out which dependencies are required for 
> the library and which are required for the tests only.
>
>> Are all of these libraries? rust-openssl-sys contained nothing, but 
>> rust-openssl-sys:src had all the data.
>
> Yeah, David added a "src" output that contains the source code.

The openssl-sys (or rather, the openssl crate) was one of these
crates which required an external, non-rust dependency to be
present. I was wondering how rust dealt with this, as I was just
following upstream description and saw that something must be
missing/broken at our end (or somewhere down my graph).

> My WIP v2 build system doesn't do that yet since I have ~5000 lines of 
> existing rust package recipes I'd have to update - and I'd rather get 
> everything to work first and then drop all my Rust packages and recreate 
> them. Keep in mind that if you want to use my WIP v2 build system you also 
> have to either (1) patch guix/build-system/cargo.scm not to do the src output 
> or (2) patch guix/build/cargo-build-system.scm to do the src output. 
> Please be advised that it's not finished yet - that's why it's marked WIP and 
> not merged :)
>
> This is all very much work-in-progress. But your Rust package recipes without 
> dependencies probably won't change later. So those are fine. The others - 
> ehhh don't know yet. For example it's not clear yet to me whether we need 
> propagated-inputs for source libs. I think we do.

I could create a branch with just those 0 dependency crates (see
below for a list including but not limited to them) and send them
to be merged? That's a base which can't be (very) wrong.

In addition I could also split off the fluid and roboto patch to
be merged.

> Right now I'm working on untangling circular dependencies manually - probably 
> have to talk to upstream some more.
>
> (Sigh... why do people so often create circular dependencies? Don't they feel 
> icky about it?)
>

I have rebased with the latest master since David just pushed the
cargo updates. Building rust-serde gave me the VM error you
mentioned earlier.


    David Craven wrote:
    
    > > Both can happen at the same time and help each other. I/we need
    > > these patches, and I think keeping this branch around on our
    > > (my)
    > > side will help finding bugs in the cargo build-system. I just
    > > hope it won't be another year until it all works well enough.

    > Well if you'd like to help there, I think that finding and
    > packaging a
    > simple package that contains a Cargo.lock file and a dependency
    > tree
    > <= 10 crates would be a more useful test scenario. A test base
    > this
    > large would be useful at a later stage. I'm having difficulties
    > finding a crate that fits those requirements, maybe I'll package
    > some
    > old rust project of mine...

    I have most dependency trees listed in our gitlab. I can
    paste the ones where I found less than 10 dependencies.
    Keep in mind I could be wrong about some as later I started
    to add not all dependencies for those I already packaged
    before. No names except the name itself means that it has 0
    dependencies, and "~" was a visual guideline for myself when
    I still used gitlab's limited markdown to track what I
    already packaged:

     futures
     log
     bitflags
     cfg-if
     void
     scoped-tls
     slab
     tempdir
     openssl-probe
     pkg-config
     rustc-serialize
     tempdir
     time -> needs: (advapi32-sys), ~log~, (kernel32-sys), ~libc~, 
rustc-serialize, (winapi)
     bitflags
     libc
     glob
     rand
     nix-test
     bytes -> needs: rand
     spin
     lazy-static
     qml (will require DOtherSide and crates: lazy-static, libc

-- 
♥Ⓐ  ng0
PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org