#25639: think about Rust crate boundaries
 Reporter:  Hello71       |          Owner:  Hello71
     Type:  enhancement   |         Status:  assigned
 Priority:  Low           |      Milestone:
Component:  Core Tor/Tor  |        Version:  Tor: unspecified
 Severity:  Normal        |     Resolution:
 Keywords:  rust          |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
Changes (by Hello71):

 * priority:  High => Low


 I have discovered that #25386 can in fact use shared libraries, so we
 don't have to do this right now.

 nevertheless, I think we have a fairly reasonable system already. I think
 the problem is in our C modules. as I understand, those currently have
 complex dependencies. if true, it will be difficult to architect our Rust
 modules in a spaghetti-free manner. we should try to untangle those
 dependencies in tandem with moving them to Rust. also, we should have some
 documentation on which modules do what in a central location rather than
 in header files. these can both be done together with Rust migration and
 would both be useful even if Tor decides not to use Rust.

 OTOH, I don't know how useful it is to actually make separate crates
 instead of one crate with modules. Rust already enforces module boundaries
 and supports "features" for conditional compilation. I'm not totally sure
 what features do, but I'm pretty sure they would work for us here. I
 talked to #rust about it at some length. I gathered that it's fine to dump
 everything together first (in separate modules of course) and then
 separate into crates when it becomes necessary, e.g. want to publish
 separately (on crates.io or otherwise), want to make a program that links
 against only a few, etc.

Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25639#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
tor-bugs mailing list

Reply via email to