Can I cfg_attr() from the crates command line?

[mark]

I am developing an fltk-rs GUI app for Windows.
At the top of my main.rs file I have:

#![cfg_attr(not(debug_assertions), windows_subsystem = "windows")]

The problem is that mostly I don't want this (because I want to see the output of dbg!() calls), but sometimes I do want it (e.g., when deploying).

At the moment the solution I'm using is to comment it out or uncomment it.

But I'd rather not have the line in my code at all and instead have a run.bat and a rundb.bat, both calling cargo run --release ... but the former with the windows_subsytem="windows" attribute, and the latter without it.

Is this possible?

[jofas]

@mark

The problem is that mostly I don't want this (because I want to see the output of dbg!() calls), but sometimes I do want it (e.g., when deploying).

The attribute you've posted is conditional and means something along the lines of: if built in release mode, use the windows subsystem. My question is, why are you manually testing in release mode? Why not simply use cargo run if you want to see your debug output, instead of cargo run --release?

[MoAlyousef]

You could probably define your own cfg and toggle it with an env variable:

// build.rs
fn main() {
    println!("cargo:rerun-if-env-changed=SHOWCONSOLE");
    if let Ok(v) = std::env::var("SHOWCONSOLE") {
        if v == "1" {
            println!("cargo:rustc-cfg=showconsole");
        }
    }
}

// main.rs
#![cfg_attr(not(showconsole), windows_subsystem = "windows")]

Run with:

SHOWCONSOLE=1 cargo run --release # to show a console
cargo run --release # or SHOWCONSOLE=whatever to not show a console

[mark]

Because I try to only ever use release mode.

[mark]

Thanks. I tried it but it didn't work in cmd.exe on Win7 or Win10. Well actually it doesn't allow that syntax, but I tried:

SET SHOWCONSOLE=1
cargo run --release

correction That works great (now that I have done it correctly). So by default & for deploy I have no console on win; but when I want the console I just set the envvar.

Thank you!

[khimru]

@MoAlyousef

You could probably define your own cfg and toggle it with an env variable:

What's the advantage here over just creating a feature which you can trigger with --features showconsole?

IMNSHO both usability and discoverability of the feature beats that of environment variable, but maybe I'm missing something.

[CAD97]

The specific answer for this case is to unconditionally set the windows subsystem and attach a console when you want it.

You can do this from an IDE/debugger ("attach to process" or similar), or make a simple program to open a console, e.g. https://www.reddit.com/r/learnrust/comments/jaqfcx/windows_print_to_hidden_console_window . There's also a command to open the console window that you can hook up to a runtime flag rather than recompiling the entire application.

[MoAlyousef]

One advantage of going the env variable route is that you can pass values to rustc-cfg. It also allows you to perform complex logic in your build script to enable/disable some other code/features.

[mark]

Yes, it does exactly what I wanted. Thanks!