Note build profile in cargo build output

[tanadeau]

Currently the output of the cargo build command does not reference the build profile (debug/default or release) anywhere in its output. This creates two issues:

1. It hurts discoverability of the release profile, especially those coming from JIT'ed/interpreted languages where that's usually not user-visible
2. Makes saved build logs harder to decipher unless the commands themselves are echoed

I propose that the output of cargo build and similar "building" commands go from:

   Compiling foo v0.0.1 (file:///Users/tanadeau/foo)

to

   Using debug build profile. Optimizations are off. Use --release to turn them on.
   Compiling foo v0.0.1 (file:///Users/tanadeau/foo)

and

   Using release build profile. Optimizations are on. Remove --release to turn them off.
   Compiling foo v0.0.1 (file:///Users/tanadeau/foo)

[tanadeau]

From @Valloric on this thread, yet another story of a user not knowing about optimizations and the --release flag in Cargo: http://www.reddit.com/r/rust/comments/2vzxjr/poor_http_performance_iron_framework/

[tomjakubowski]

I'd like to add a suggestion that this nag message could be disabled via a Cargo config flag.

Also, it isn't necessarily true that the release profile is optimized and the debug profile is not, so Cargo should probably check these things before printing those messages.

[alexcrichton]

I do agree that this does seem like a problem, but I really do worry about non-newbie users. As soon as you know the difference you never want to see this message again, and I suspect that all Rust programmers will eventually know the difference. This means that if configuration is required it will mean that all Rust programmers will want that configuration. This indicates to me that it may be the wrong default.

It's definitely a tricky problem figuring out the best way to show this, but I just wanted to lay out some of my own personal worries.

[tanadeau]

@alexcrichton I'm not sure I understand why it would be an issue. It's a one-line message that should only show up when the "Compiling foo..." notice would appear anyway. Even for non-newbie users it would be useful as a configuration check like "whoops, I forgot to pass --release that time".

I would definitely agree more if cargo build gave only error output unless a --verbose flag was added, but that's not the case.

[steveklabnik]

In general, I tend to prefer the Unixism of 'dont print anything unless it's unexpected'. We don't exactly keep to that in Cargo, but there's a number of these kinds of suggestions to keep adding things to the output.

[tanadeau]

@steveklabnik If Cargo did that, then all of the current notices about compiling, downloading dependencies, etc. would not be printed either.

[steveklabnik]

I know.

[tanadeau]

I don't know of any build systems off the top of my head that are completely silent by default.

[kornelski]

I wouldn't like extra "educational" lines in the output (they get boring quickly), but perhaps the existing "Compiling…" line could be changed accordingly from:

Compiling foo v0.0.1 (file:///Users/tanadeau/foo)

To something like:

Building debug/unoptimized foo v0.0.1 (file:///Users/tanadeau/foo)

[Ryman]

For cargo run we already print "Running target/examples/blah" we could append " with optimisations OFF" or similar.

[alexcrichton]

Having the debug/release folders has ended up meaning that I haven't seen this in quite some time, so I'm going to close this for now as the debug/release folder seems to be sufficient.

[Valloric]

Running a "debug" binary provides zero indication to developers coming from Ruby, Python, Java, JavaScript, C# or the other languages that together make up 90% of all modern development that the binary is vastly slower than a release build. We've been over this many, many times now. Dozens of people have pointed this out in discourse threads, RFC comments, r/rust discussions etc.

"Debug" is not enough. There needs to be something telling these users that an unoptimized build is being produced/run. Running a binary from a folder named "debug" does not convey this information.