unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ng0 <ng0@n0.is>
To: Danny Milosavljevic <dannym@scratchpost.org>
Cc: guix-devel@gnu.org
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	[thread overview]
Message-ID: <20171207205921.lt4x2cks56osz2uy@abyayala> (raw)
In-Reply-To: <20170403003524.63b96e32@scratchpost.org>

[-- Attachment #1: Type: text/plain, Size: 3563 bytes --]

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,
> 
> On Sat, 1 Apr 2017 07:58:41 +0000
> ng0 <contact.ng0@cryptolab.net> wrote:
> 
> > Danny, could you list what's left for completion? Is it just circular
> > dependencies? 
> 
> Very little is missing:
> - Rustc and cargo should be disentangled.  Right now they have to be updated 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 that (bootstrapping rustc) in the long run?
Is it even possible at this point to bootstrap rustc using OCaml without wasting 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 present we assume
> that it's an application, and if there isn't one we assume that it's a library.
> 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 support
> version ranges but cargo does.  If multiple libraries depend on the same library
> with differing API version ranges, cargo uses an version range intersection
> 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.

> 
> 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.
> 
> Okay.

-- 
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys
  WWW: https://n0.is

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2017-12-07 20:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-01  7:58 the importance of rust-build-system [Fwd: [tor-dev] Tor in a safer language: Network team update from Amsterdam] ng0
2017-04-01 18:58 ` Leo Famulari
2017-04-01 22:22   ` Ludovic Courtès
2017-12-08 10:04     ` ng0
2017-04-02 13:02 ` ng0
2017-04-02 13:05   ` ng0
2017-04-02 22:35 ` Danny Milosavljevic
2017-12-07 20:59   ` ng0 [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171207205921.lt4x2cks56osz2uy@abyayala \
    --to=ng0@n0.is \
    --cc=dannym@scratchpost.org \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).