From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Craven Subject: Re: 77 Rust Crates, fluid, roboto-font, libpsyc rust bindings Date: Thu, 5 Jan 2017 21:34:39 +0100 Message-ID: References: <20170103233642.3181-1-ng0@libertad.pw> <87lguqim4o.fsf@gnu.org> <8760luh2zk.fsf@wasp.i-did-not-set--mail-host-address--so-tickle-me> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42198) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cPEkH-00041g-R1 for guix-devel@gnu.org; Thu, 05 Jan 2017 15:34:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cPEkE-0003Qd-O0 for guix-devel@gnu.org; Thu, 05 Jan 2017 15:34:45 -0500 Received: from mail-qk0-x234.google.com ([2607:f8b0:400d:c09::234]:33114) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cPEkE-0003QN-Iy for guix-devel@gnu.org; Thu, 05 Jan 2017 15:34:42 -0500 Received: by mail-qk0-x234.google.com with SMTP id s140so32263362qke.0 for ; Thu, 05 Jan 2017 12:34:40 -0800 (PST) In-Reply-To: <8760luh2zk.fsf@wasp.i-did-not-set--mail-host-address--so-tickle-me> 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: ng0 Cc: guix-devel > I understand the concerns of David Craven regarding > =E2=80=98cargo-build-system=E2=80=99, though OTOH I=E2=80=99m tempted to = think > =E2=80=98cargo-build-system=E2=80=99 is probably not so bad if it managed= to build all > this. ;-) But anyway, I=E2=80=99ll David and you figure out what the be= st > approach is! I haven't inspected all the patches, but I don't think it's possible that any package was actually built (unless danny's patch was applied). All the build-system does with these packages is recursively download the rust-psych dependency tree without building anything. This would not show any problems with some crates requiring a nightly rustc, or circular dependencies, or version mismatches (like requiring an older semver major version or multiple versions of the same package). The downside of doing it like this is that we can't run tests on the dependencies. But I think that building binaries like cargo that have locked dependencies side steps all the problems mentioned above, and would be a big milestone. It would allow us to do cool things like patch crates with security fixes; and c wrapper crates like rust-pkg-config, rust-cmake, rust-openssl, etc. could declare/propagate/retain their c dependencies directly. Danny has been exploring a different (or complementary) approach that would allow running the tests on the crates and solves the above issues manually. I currently think that doing this manually would make packaging and much more important updating packages a large amount of manual work, but I am open to reconsider if someone shows this to be a surmountable task. Another issue with Danny's approach is that as it is now, I don't see an immediate advantage of running tests on dependencies of a package before we have managed to build the package. The reason being that trying to use the latest versions of all packages recursively might yield big issues when trying to build the final thing even if all tests passed on the individual crates. This results in false confidence in the taken path and I don't think it can be considered a reliable intermediate step to packaging a rust package, as it would be in other build-systems. At least not until someone has provided evidence by showing at least one counter example.