From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0 Subject: Re: 77 Rust Crates, fluid, roboto-font, libpsyc rust bindings Date: Wed, 04 Jan 2017 12:24:33 +0000 Message-ID: <87h95f108u.fsf@wasp.i-did-not-set--mail-host-address--so-tickle-me> References: <20170103233642.3181-1-ng0@libertad.pw> <87vatv13ex.fsf@wasp.i-did-not-set--mail-host-address--so-tickle-me> <20170104123933.6323991a@scratchpost.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36738) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cOkcR-0005Nw-Tz for guix-devel@gnu.org; Wed, 04 Jan 2017 07:24:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cOkcN-000791-Pt for guix-devel@gnu.org; Wed, 04 Jan 2017 07:24:39 -0500 Received: from aibo.runbox.com ([91.220.196.211]:52296) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cOkcN-00078A-Eb for guix-devel@gnu.org; Wed, 04 Jan 2017 07:24:35 -0500 In-Reply-To: <20170104123933.6323991a@scratchpost.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Danny Milosavljevic Cc: guix-devel@gnu.org Danny Milosavljevic 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