Add release and debug target indicators #2896

sophiajt · 2016-07-19T20:05:24Z

This resurrects #1374 and implements an indicator of whether the current build is a release or debug. This should help avoid issues like

https://www.reddit.com/r/rust/comments/4tikmf/why_is_my_forth_virtual_machine_written_in_rust/

Specifically, this change includes the target indicator, as @alexcrichton mentions in the original PR:

# old
Compiling foo v0.1.0

# new
Compiling (debug) foo v0.1.0

r? @alexcrichton

rust-highfive · 2016-07-19T20:05:37Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

alexcrichton · 2016-07-19T20:45:59Z

cc @rust-lang/tools, thoughts on this?

I personally think that because this is still coming up it's worth doing something, and the modification to the output here should be quite un-invasive.

vadimcn · 2016-07-19T21:25:11Z

+1

brson · 2016-07-19T21:53:15Z

I like the idea of putting the target (or profile or whatever this is) into the output to give people a clue they are not optimizing, but with this implementation it will print redundantly for each crate, since it's a global setting. Unfortunately there are no other status lines to tack it onto. We could output a new line just dedicated to communicating dynamic configuration properties (maybe there are others), like Configuring for debug build.

sophiajt · 2016-07-19T21:54:21Z

I'd be fine with @brson's fix also, assuming we're okay with adding an extra line to the build output.

sophiajt · 2016-07-19T21:58:09Z

On second thought, we might want to consider that being more "in your face" like this PR does might help prevent the error we're trying to avoid better than having a line that they may miss if it scrolls off the screen building dependencies...

alexcrichton · 2016-07-19T21:59:16Z

I do kinda like that a noop cargo build doesn't print anything today, but we could probably just defer printing something like "configuring for a debug build" unless something's actually built. It is conceivable in the future there we could build some dependencies in release mode and some in debug mode, but you also perhaps don't need to be informed of this.

For a comparison, here's what this would look like with a few deps:

    Updating git repository `https://github.com/carllerche/slab`                     
    Updating registry `https://github.com/rust-lang/crates.io-index`                 
   Compiling void v1.0.2                                                             
   Compiling bytes v0.3.0                                                            
   Compiling libc v0.2.14                                                            
   Compiling log v0.3.6                                                              
   Compiling slab v0.2.0 (https://github.com/carllerche/slab?rev=5476efcafb#5476efca)
   Compiling cfg-if v0.1.0                                                           
   Compiling semver v0.1.20                                                          
   Compiling bitflags v0.4.0                                                         
   Compiling rustc_version v0.1.7                                                    
   Compiling net2 v0.2.26                                                            
   Compiling nix v0.6.0                                                              
   Compiling mio v0.6.0-dev (file:///home/alex/code/mio)

vs

    Updating git repository `https://github.com/carllerche/slab`                     
    Updating registry `https://github.com/rust-lang/crates.io-index`                 
   Compiling (debug) void v1.0.2                                                             
   Compiling (debug) bytes v0.3.0                                                            
   Compiling (debug) libc v0.2.14                                                            
   Compiling (debug) log v0.3.6                                                              
   Compiling (debug) slab v0.2.0 (https://github.com/carllerche/slab?rev=5476efcafb#5476efca)
   Compiling (debug) cfg-if v0.1.0                                                           
   Compiling (debug) semver v0.1.20                                                          
   Compiling (debug) bitflags v0.4.0                                                         
   Compiling (debug) rustc_version v0.1.7                                                    
   Compiling (debug) net2 v0.2.26                                                            
   Compiling (debug) nix v0.6.0                                                              
   Compiling (debug) mio v0.6.0-dev (file:///home/alex/code/mio)

The latter to me doesn't look so bad, but I don't really mind so long as we fit it in somewhere.

Also one thing we may want to keep in mind is that if we print out the build type at the top then it's likely to get lost in a project like servo which has tons of deps.

michaelwoerister · 2016-07-19T22:13:19Z

I'm definitely in favor of the general idea; and I also think that this specific implementation where the (debug) hint is given for each dependency is quite OK. It's still very readable output.

brson · 2016-07-19T22:13:32Z

Yeah, printing critical info first isn't so great because it will scroll off screen.

brson · 2016-07-19T22:14:37Z

Alex's example looks fine to me.

eddyb · 2016-07-19T22:29:28Z

It might be worth having "Debug (unoptimized+debuginfo)" at least once, to make it painfully obvious that optimizations aren't enabled.

steveklabnik · 2016-07-19T22:39:50Z

Also one thing we may want to keep in mind is that if we print out the build type at the top then it's likely to get lost in a project like servo which has tons of deps.

we could, in theory, print it just on your own crate. Then you'd have something like

    Updating git repository `https://github.com/carllerche/slab`                     
    Updating registry `https://github.com/rust-lang/crates.io-index`                 
   Compiling void v1.0.2                                                             
   Compiling bytes v0.3.0                                                            
   Compiling libc v0.2.14                                                            
   Compiling log v0.3.6                                                              
   Compiling slab v0.2.0 (https://github.com/carllerche/slab?rev=5476efcafb#5476efca)
   Compiling cfg-if v0.1.0                                                           
   Compiling semver v0.1.20                                                          
   Compiling bitflags v0.4.0                                                         
   Compiling rustc_version v0.1.7                                                    
   Compiling net2 v0.2.26                                                            
   Compiling nix v0.6.0                                                              
   Compiling (debug) mio v0.6.0-dev (file:///home/alex/code/mio)

Messes up the symmetry a bit though :/

sophiajt · 2016-07-19T22:41:26Z

@steveklabnik - yeah, @wycats mentioned that as a possibility as well. I'm not a fan, yeah, for the symmetry, but it also kinda begs the question "what are the deps being built with?" Are they release and only mine is (debug), which is why it's specifically called out?

alexcrichton · 2016-07-19T22:42:51Z

Another possibility (which I believe solves @eddyb's concern as well) is that we could print one line at the end of a build along the lines of:

Finished debug (unoptimized + debuginfo) build of N crates in 4.53s

That way we can add extra information like how many crates were built, how long the build took, etc

wycats · 2016-07-22T17:35:51Z

Finished debug (unoptimized + debuginfo) build of N crates in 4.53s

I'm much, much, much more comfortable with one line at the end describing the build than adding a bit of extra info to every line. At some point, that extra info gets tuned out and just adds noise.

alexcrichton · 2016-07-22T17:48:07Z

I'm ok with that as well, @jonathandturner do you want to update with that on this PR?

sophiajt · 2016-07-23T03:14:31Z

@alexcrichton - yeah, alternate PR on #2909. If that works, I can close this one.

alexcrichton · 2016-07-25T23:25:16Z

Closing in favor of #2909, I think we're gonna take the strategy there

…crichton Switch to output release/debug after compile This is similar to #2896 but instead of inline, it puts an indicator at the bottom showing if it was a release or debug build. ``` jturner-23759:cargo jturner$ ./target/release/cargo build Finished debug (unoptimized + debuginfo) build. jturner-23759:cargo jturner$ ./target/release/cargo build --release Finished release (optimized) build. ```

Add (release) and (debug) target indicators

074c4af

rust-highfive assigned alexcrichton Jul 19, 2016

sophiajt mentioned this pull request Jul 19, 2016

Re-open discussion around mentioning the target #2894

Closed

brson added the relnotes Release-note worthy label Jul 19, 2016

sophiajt mentioned this pull request Jul 23, 2016

Switch to output release/debug after compile #2909

Merged

alexcrichton closed this Jul 25, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add release and debug target indicators #2896

Add release and debug target indicators #2896

sophiajt commented Jul 19, 2016

rust-highfive commented Jul 19, 2016

alexcrichton commented Jul 19, 2016

vadimcn commented Jul 19, 2016

brson commented Jul 19, 2016 •

edited

Loading

sophiajt commented Jul 19, 2016

sophiajt commented Jul 19, 2016

alexcrichton commented Jul 19, 2016

michaelwoerister commented Jul 19, 2016 •

edited

Loading

brson commented Jul 19, 2016

brson commented Jul 19, 2016

eddyb commented Jul 19, 2016

steveklabnik commented Jul 19, 2016

sophiajt commented Jul 19, 2016

alexcrichton commented Jul 19, 2016

wycats commented Jul 22, 2016

alexcrichton commented Jul 22, 2016

sophiajt commented Jul 23, 2016

alexcrichton commented Jul 25, 2016

Add release and debug target indicators #2896

Add release and debug target indicators #2896

Conversation

sophiajt commented Jul 19, 2016

rust-highfive commented Jul 19, 2016

alexcrichton commented Jul 19, 2016

vadimcn commented Jul 19, 2016

brson commented Jul 19, 2016 • edited Loading

sophiajt commented Jul 19, 2016

sophiajt commented Jul 19, 2016

alexcrichton commented Jul 19, 2016

michaelwoerister commented Jul 19, 2016 • edited Loading

brson commented Jul 19, 2016

brson commented Jul 19, 2016

eddyb commented Jul 19, 2016

steveklabnik commented Jul 19, 2016

sophiajt commented Jul 19, 2016

alexcrichton commented Jul 19, 2016

wycats commented Jul 22, 2016

alexcrichton commented Jul 22, 2016

sophiajt commented Jul 23, 2016

alexcrichton commented Jul 25, 2016

brson commented Jul 19, 2016 •

edited

Loading

michaelwoerister commented Jul 19, 2016 •

edited

Loading