Consider --version output more carefully

[brson]

The output of --version is often grepped, so it needs to be parsable and stable, and our current output has not been thought through quite enough.

Here are two examples of its current output:

brian@brian-X1:~$ rustc --version
rustc 0.11-pre-nightly (e332287 2014-04-16 00:56:30 -0700)
host: x86_64-unknown-linux-gnu
brian@brian-X1:~$ /usr/local/bin/rustc --version
/usr/local/bin/rustc 0.11-pre-nightly (e332287 2014-04-16 00:56:30 -0700)
host: x86_64-unknown-linux-gnu

The name rustc is actually arg[0], so it changes depending on how rustc is invoked. This makes it very hard to parse rustc's version. Note also that the info in parens is only present in git builds, so it can't be relied on.

The one obvious fix is to hardcode rustc as the program name. As long as we leave the first line using a consistent format forever we should be mostly ok.

The host: ... line in our output is non-conventional and might properly be put under another flag or remove it; alternately, we may want to include more info here - why is 'host' special?

For comparison, here are some other --version outputs on my system:

brian@brian-X1:~$ gcc --version
gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

brian@brian-X1:~$ perl --version

This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-gnu-thread-multi
(with 80 registered patches, see perl -V for more detail)

Copyright 1987-2011, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.

brian@brian-X1:~$ python --version
Python 2.7.4

Also, make rustdoc consistent with whatever format is preferred.

Nominating.

[flaper87]

FWIW, I prefer python's style. 1 line with the actual required info.

[brson]

@flaper87 that strategy sounds good to me. We need to figure out why host: was added and if it needs to remain under a different flag.

[flaper87]

@brson took the time to dig into the history. This is the commit that added the triple: 68d50b5 No special reason stated there.

I'm now thinking it may probably make sense to keep it. Here's the output from other comands:

$ clang --version
clang version 3.3 (tags/RELEASE_33/final)
Target: x86_64-redhat-linux-gnu
Thread model: posix

$ llc --version
LLVM (http://llvm.org/):
  LLVM version 3.3
  Optimized build.
  Built Dec 20 2013 (11:50:05).
  Default target: x86_64-redhat-linux-gnu
  Host CPU: core-avx-i

  Registered Targets:
    aarch64 - AArch64
    arm     - ARM
    cpp     - C++ backend
    nvptx   - NVIDIA PTX 32-bit
    nvptx64 - NVIDIA PTX 64-bit
    ppc32   - PowerPC 32
    ppc64   - PowerPC 64
    r600    - AMD GPUs HD2XXX-HD6XXX
    systemz - SystemZ
    thumb   - Thumb
    x86     - 32-bit X86: Pentium-Pro and above
    x86-64  - 64-bit X86: EM64T and AMD64

[brson]

1.0 backcompat libs.

[anemator]

How about key-value pairs to further ease parsing?

rustc: VERSION
commit-id: SHA1
commit-date: DATE
host: HOST

where commit-id/date are simply listed as "unknown" if built from tarball; the VERSION [git tag] will work just as effectively for referencing the commit in that case.

[pnkfelix]

my suggestion: --version should use a python style one-liner, targetted at human readers. I don't mind if we keep using args[0] for the name, (since its targetting, as I said, human readers). But it would be nice if we kept it restricted to one line.

--version=verbose (or something along those lines) should produce the same first line as --version, followed by a series of key-value pairs along the lines suggested by @anemator. All of the info in the first line should be derivable via output included in the series of key-value pairs. I.e. I want the first line to be 100% redundant, deliberately.

Then scripts can interact with the output produced by --version=verbose (by dropping the first line), while humans get to look at whichever they like.

[flaper87]

+1 for @pnkfelix suggestion.

[pnkfelix]

Incidentally, it would be nice if the verbose output even included relevant configure flags such as whether it was built with --enable-debug and/or --enable-optimize.

Of course if one mixes-and-matches crates then that may not be a meaningful bit of metadata to ask for. Maybe instead it could print out that sort of metadata (i.e. compilation flags for debug and optimization level) for each crate that rustc is pulling in... but I'm just thinking off the top of my head.

[anemator]

Sure, I like that idea too. Thanks

[brson]

Nominating for removal from milestone. There's more that can be done here, but at least the version number should be consistently parsable.

[emberian]

Having the host is useful for tools which want to look for host libs (how else do you know what the host is?) but that presumably doesn't need to be part of --version

[pnkfelix]

Assuming we're committing to the format of the first line, it seems we can live with people parsing the first line if it comes to that. (though I personally would still prefer the stable output to be accessed via something like --version=verbose, perhaps offered via a diferent UI.)

Reassiging to P-low and removing from milestone.

[brson]

One of my concerns with the suggested --version=verbose patch is that I don't recall seeing other commands support --version=verbose. If there's a more common way to do this then we should stick with convention.

[alexcrichton]

Closed by #13816 and co.