From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0 Subject: Re: the importance of rust-build-system [Fwd: [tor-dev] Tor in a safer language: Network team update from Amsterdam] Date: Thu, 7 Dec 2017 20:59:21 +0000 Message-ID: <20171207205921.lt4x2cks56osz2uy@abyayala> References: <20170401075841.242czleuqvibqmjf@abyayala> <20170403003524.63b96e32@scratchpost.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3t3cgxpckp6g2twv" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35704) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eN3GV-0008EU-1a for guix-devel@gnu.org; Thu, 07 Dec 2017 15:59:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eN3GR-0001du-Tn for guix-devel@gnu.org; Thu, 07 Dec 2017 15:59:31 -0500 Received: from aibo.runbox.com ([91.220.196.211]:47084) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eN3GR-0001ct-KC for guix-devel@gnu.org; Thu, 07 Dec 2017 15:59:27 -0500 Content-Disposition: inline In-Reply-To: <20170403003524.63b96e32@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 --3t3cgxpckp6g2twv Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, my apologies. Occasionally I have a tendency for very late replies in some threads, as you might have noticed. Danny Milosavljevic transcribed 1.9K bytes: > Hi ng0, >=20 > On Sat, 1 Apr 2017 07:58:41 +0000 > ng0 wrote: >=20 > > Danny, could you list what's left for completion? Is it just circular > > dependencies?=20 >=20 > Very little is missing: > - Rustc and cargo should be disentangled. Right now they have to be upda= ted in lockstep. That's not really a problem for producing functional rust crate binaries. I consider this optional. Or am I wrong? > - Rust has a new optional maker (instead of makefiles) called rustbuild; > for some reason I didn't get it to work. Future versions will drop > the makefiles, so we have to get it to work eventually. Can you share the issues you had with this? How far did you come? > - Eventually we could try to bootstrap a Rust compiler from the > original ocaml sources. I'm trying to do that now but it's still > broken. It would be fine to make it memory-safe by just not > freeing anything ever - since it would only be used to compile the > Rust compiler. Wouldn't it be easier to help the mrustc project, which is aimed at just th= at (bootstrapping rustc) in the long run? Is it even possible at this point to bootstrap rustc using OCaml without wa= sting too much resources? They've come a long way and many releases since they've gone selfhosted. Can you share your findings and work on this? > - Earlier we had an heuristic in that if there's a Cargo.lock file presen= t we assume > that it's an application, and if there isn't one we assume that it's a li= brary. > Not sure how safe that heuristic is. What's the official way to find out= what it is? > - There's a design limitation in that our rust build system doesn't API s= upport > version ranges but cargo does. If multiple libraries depend on the same = library > with differing API version ranges, cargo uses an version range intersecti= on > algorithm in order to find out which implementation version to use. > We don't do that - although we do use cargo, so it will fail in that case= (and > not do something invalid silently). Can you explain this a bit more in detail? You seem to have put more time to work/think about these issues than I have done so far. I need to understand most of the issues, so that I can communicate them to people who'd work on them. At least to get them started on the issues. > Note that Rust itself makes a distinction between stable features that > are guaranteed to stay and stay > the same in the future and unstable features that don't. > Many Rust crates use unstable features, among them very basic crates. > That makes us unable to use them, and rightfully so. You mean fundamental basic crates required by many applications? Do you have some insight into the implications of this? I would provide a rustc-nightly outside of Guix master/official, that's not an issue for me. >=20 > Other than that I've got a big number of (unpolished) Rust packages that = do work. Can you share these package definitions somewhere? I'd like to help out and see how many intersections (duplicates) we both have in our unfinished rust crates work. > > days. I hope you don't mind if I list you as a go-to person for getting > > involved in upstream (Guix) to fix up the rust-build-system. >=20 > Okay. --=20 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys WWW: https://n0.is --3t3cgxpckp6g2twv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEqIyK3RKYKNfqwC5S4i+bv+40hYgFAlopq6QACgkQ4i+bv+40 hYgIHQ/8C23lZzXGy6O/BVZ2v7t87M7xWd+cB4gjxZ/XycNKkdG79WTpxVWjySoo c6/PsCO5O8kCnuvdZ7BGDGCzIYSjwYOC0pf4B689096vQTEZ4k8Zw9x+FB1YYeuf dTN+kyphOWPzzT6NL8sg2FS4aaMoA17x2bsC9CD/fdl1zNvcE/b7d5Uk7N3slOA2 KV32eIJfIFz7c7Ozy2pB4br180i3COJeXRI1X43gweIGLs1ShKVlThGVyxHiJxg7 0qh3dV96X5iwqmFpNHIjyIXxkj5uQIbXFKaeLJdFpRacInE33KtUC3iXMXizjDeo sk4U2bU0gLtrNfTRuns9QYvyZ1G1sP66+E4VFxXenWnednjKY6nIPjtEKRphkHFw irQJNDxTy/ZVGYwtPStEnGjNmAgf7qSGjcJ93TbrFa/iXk0xtPGSm9YJ9BBL12Ex n+rXJp2oHIIcLCBWWxtXD4IpmCNejvsodnW0bH/hD7aIk/SMGON0K3ZCGjjLwB0f aNcG7bMx0P/iawa6PNlTB6+4Y03lD1BvGvklhVMVpXcq0/oFG0Wj4JPzg0HkCDhq 2ddj5T8Hln4BIHaQw3v5uJ8QVwqwSnQEiSL2nAbsdSOzovy3N73Wnl8oPUPICp1m CR3TDAgaDNul4MllYbrCCluc30uNQk4pOKZLacmaVd/bMdFmQvI= =6s6p -----END PGP SIGNATURE----- --3t3cgxpckp6g2twv--