[rust-dev] tool interfaces

Graydon Hoare graydon at mozilla.com
Tue Apr 24 10:40:45 PDT 2012


There's been some casual conversation on IRC and around mozilla lately 
about the longer-term evolution of tool interfaces (command-line and 
crate/library interfaces) for rust. I thought I'd poll the mailing list 
a bit and see if anyone has strong opinions. Here is what's been discussed:

1. Creating an 'outermost' command-line tool called simply "rust", 
through which any remotely rust-related sub-tool can be discovered (and 
invoked as "rust <subcommand> <options") This is following in the 
footsteps of other broad tool-sets such as git (and more recently go).

2. Renaming sub-tools rustc, rustdoc, fuzzer and cargo to a uniform 
naming scheme (either, say, renaming the latter two to "rustfuzz" and 
"rustpkg", or perhaps renaming them all to hyphen-names like 
"rust-compile", "rust-doc", "rust-fuzzer", "rust-package")

3. Merging tools or splitting them. Moving cargo functionality into 
rustc, for example (name a link requirement in a crate => download and 
compile it as a dependency). Generating docs as part of a compilation pass.

4. Moving more of the compiler to separate crates with their own library 
interfaces, LLVM-like, to make it easy to make tools with different 
command-line interfaces, but shared code paths.

It should not escape notice that these topics are somewhat contradictory 
or at least pulling the problem in multiple directions at once. That's 
fine, it just points to the existence of a problem-space we need to 
adopt strategy around. Currently we don't have much of a _strategy_. As 
in, not many really clear organizing principles for where to draw lines 
between crates or tools.

I'm polling the list here mostly to request advice on such principles. 
What are some ways you'd divide responsibility between command line 
tools? How many should we aim for? One tool per general role of 
developer? One tool per intended man page? One tool per different 
default interpretation of an unadorned command-line argument? One tool 
per step in a build process? One tool ("rust") with all subcommands as 
merely library calls? Some other principle?

Thoughts, opinions?


More information about the Rust-dev mailing list