#22106: Initial Rust support
--------------------------+------------------------------------
Reporter: Sebastian | Owner:
Type: defect | Status: needs_revision
Priority: Medium | Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
--------------------------+------------------------------------
Comment (by Sebastian):
Replying to [comment:10 teor]:
> Replying to [comment:9 Sebastian]:
> > Replying to [comment:8 teor]:
> > > Replying to [comment:7 Sebastian]:
> > > > > I think it's ok to expect people to install rust's libc: we
already do this with libevent and {open,libre,*}SSL. They'll have to
install rust, so installing libc is a reasonable ask.
> > > >
> > > > I don't know what you mean with install rust'c libc. It's a crate
that needs to be available during building, not a dynamic library you can
link to or something. The crate provides bindings for different host libc
implementations.
> > >
> > > Oh, ok, then yes, a local crates mirror seems sensible.
> > > And a make target to set it up. I can't quite work out how to do it!
> >
> > There's a subcommand for cargo called vendor (not installed
automatically) that can do that. I can add a make target for it once we
decided which of the options for mirroring we're taking.
>
> When I ran the rust build without the crates, it failed halfway through
make.
> Can we check at configure time instead?
> That's when we fail if we don't have other dependencies installed.
Of course we will do that, but since different mechanisms are required for
the different potential solutions I outlined above, none of them are
implemented right now. See the note about it failing unless dependencies
are in Cargo's cache, in the first post here. This seems unrelated to
making vendoring easier.
> Then we would need the rust dependencies to be a shell script (or a line
in the rust install doc), not a make target.
>
> > ...
> > > Is there a linter (?) or style checker (make check-spaces) that we
might want to run?
> >
> > There's both, clippy (a linter, requires Rust nightly) and rustfmt.
Not yet sure how to best integrate them. Both are rapidly evolving.
>
> My experience with rustfmt is that it wraps to 100 characters by
default. We probably want 79 to match our C standards:
>
https://gitweb.torproject.org/tor.git/tree/doc/HACKING/CodingStandards.md#n125
We already do that via a config file. I forgot to add it to the commits
here, but it's added now.
> And we want to wrap comments as well.
>
> We could actually enforce formatting, which would be nice.
This is harder to do than it appears, because it requires everyone to be
in sync with rustfmt versions. Since a tool exist that can reformat, I
would like to not require it at first except at the review stage, and then
explore our options.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22106#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
