Support cargo:info=MESSAGE in build.rs stdout

[fredericvauchelles]

Describe the problem you are trying to solve
Provide meaningful information to a developer when using a build.rs script.
In my case, I provide duration of specific steps to monitor the performance of thoses.

Currently, I use cargo:warning=MESSAGE to provide this output.

This is not fine because it is not an actual warning.

Describe the solution you'd like

Supporting cargo:info=MESSAGE to output a string in the cargo's output with info log level.

Example:
(build.rs)

fn main() {
     println!("cargo:info=Hello World!");
}

Will print in the cargo output if the build.rs script is executed:

info: Hello World!

with the look of an info entry.

[Fishrock123]

This would be quite useful.

[davidkern]

I was looking at putting up a PR for this, but after looking at the code, I can see there is some more discussion needed first.

Internally, cargo has support for printing "warn", "error" and "note" messages to the shell. For consistency, I suggest this feature should be implemented as "cargo:note=MESSAGE" which would print the cyan note message. Additionally, similar functionality should be implemented for "error" as well (presumably error would also trigger cargo to abort).

A complication with the existing architecture is that messages are collected from the custom build script and are not written to the console until after the build script has completed. Would this restriction still support the motivating use cases for this feature?

In my use case, waiting until the end of the build script would not be sufficient. I have a build which requires the presence of a 500MB archive, which is downloaded if not present. I want to display a note to the user that this download is in progress, otherwise the impression is that cargo build has hung, particularly on slow connections.

[joshtriplett]

We talked about this in today's @rust-lang/cargo meeting.

A summary of the rough consensus:

• This needs design work, and an RFC; we don't just want to do this via PR.
• Info messages should not show up by default, only if you pass -v or similar. We're concerned about this being misused if visible by default. The equivalent in npm, for instance, is sometimes used for advertisements.
• We'd be interested in a more narrowly scoped mechanism for cargo:progress= messages, which would only carry numeric progress information (e.g. percentage done); Cargo's own progress could then show something like cratename(build x%), and that could be shown by default. Such a mechanism would need to allow for multiple progress indicators from the same crate, because this would almost certainly come primarily from helper crates rather than from build scripts directly. (For instance, the cc or cmake crates could give progress indicators for their builds, or a common download helper crate could provide progress indicators for its downloads.) We don't want such a mechanism to introduce too much complexity, but a simple tag+number system might work.

[togetherwithasteria]

Info messages should not show up by default, only if you pass -v or similar. We're concerned about this being misused if visible by default. The equivalent in npm, for instance, is sometimes used for advertisements.

Yeah, that would be a problem, but I think this might be useful too for . We can perhaps allow logs from certain crates with configuration or/and crates that are locally hosted (rather than fetched from Crates.io)?

[codecnotsupported]

If you want a workaround you can abuse escape codes to overwrite the line with something new.

macro_rules! p {
    ($($tokens: tt)*) => {
        println!("cargo:warning=\r\x1b[32;1m   {}", format!($($tokens)*))
    }
}

p!("Compiling XYZ");

[epage]

This is also blocked on #11461 being resolved..

[weihanglo]

I overlooked at that time. #11593 seems kinda a duplicate of this?

[epage]

Isn't #11593 about non-cap-lint build script warnings while this is about info messages?

[newcomertv]

Hey, what's the status on this?

There are legitimate use cases for printing general build info like when using an environment variable that will be overridden with a default value if not found.

Anything I can help with?

[epage]

Within cargo's current model, that sounds like something that would be gated behind verbose output. iirc build script output is shown on verbose (or is it very verbose) output. What additional value would info then provide over printing it yourself?

[tklajnscek]

Hey, I stumbled back into this after a few years to find it still open :)

I think the key distinction here is that you want to show some kind of potentially important message, but not the entire output of the build script.

Our use case is - we have cargo.toml metadata field that can switch between building CMake dependencies locally vs downloading them prebuilt. It would be super nice if I could output:
Building CMake dependencies!
or
Downloading pre-built dependencies!
within the usual progress output cargo prints already such as:

==================== Compiling executable ====================
   Compiling bla v0.0.23
   Compiling xyzv0.0.23 

[epage]

Not that the "currrent operation" ("Compiling") would be unlikely to be overriden because that reflects a concurrent operation and trying to analyze what should be shown would be tricky. This just leaves the sticky result ("Compiled"). I can understand wanting to show nuance for very different build script operations but we also have a lot of people not thrilled with how much we output (on top of the abuse seen in other ecosystemsb) and we're looking at redoing our output in #8889. What we'd want from an "info status" after that may be very different