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

[ng0 <ng0@libertad.pw>]

Danny Milosavljevic <dannym@scratchpost.org> 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