[rust-dev] tool interfaces

Brian Anderson banderson at mozilla.com
Tue Apr 24 11:26:19 PDT 2012


On 04/24/2012 10:40 AM, Graydon Hoare wrote:
> Hi,
>
> 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:

There's an issue open here:

https://github.com/mozilla/rust/issues/2238

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

This is my main interest. Whatever the resulting UI looks like I want 
everything to be factored into libraries and not all dumped into rustc.

> 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?

My preference is that every tool is a library crate that exports a known 
interface. There is one driver that knows how to discover and load 
libraries that implement this interface. We have many configurations of 
the driver that restrict it to just the rustdoc tool, etc. and one 
'master' configuration that can drive all available tools.

Users can create libraries that implement this interface and publish 
them via cargo to add features to the Rust toolchain.

>
> Thoughts, opinions?
>
> -Graydon
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev



More information about the Rust-dev mailing list