[rust-dev] tool interfaces

Benjamin Striegel ben.striegel at gmail.com
Tue Apr 24 10:59:46 PDT 2012


Here's a summary of Go's subcommands, which could be useful for a starting
point:

build       compile packages and dependencies
clean       remove object files
doc         run godoc on package sources
env         print Go environment information
fix         run go tool fix on packages
fmt         run gofmt on package sources
get         download and install packages and dependencies
install     compile and install packages and dependencies
list        list packages
run         compile and run Go program
test        test packages
tool        run specified go tool
version     print Go version
vet         run go tool vet on packages


Not intending to throw more fuel on the Rust vs. Go fire, but they do have
a lot of good ideas! :)

On Tue, Apr 24, 2012 at 1:40 PM, Graydon Hoare <graydon at mozilla.com> 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:
>
> 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?
>
> -Graydon
> ______________________________**_________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20120424/08b9dc68/attachment-0001.html>


More information about the Rust-dev mailing list