If by "interactive mode" you mean "stdout is a terminal" then that could be a way to have it both ways, yeah.
I think a decent option here would be a an indicatif
MultiProgress that shows each crate as it gets compiled, but removes them after the compilation is done (maybe only if successful?). If we want to get a fancy about it, it's possible to make that kind of tree-like such that you get a better sense of which nodes in your dependency graph are contributing to your compile time.
Before going too far into design, I'd recommend resolving the concern my earlier comment
- We more exhaustively test various terminals
- We make this a
termsetting with an "auto detect" that works off of a
TERMverified list and provide a process for people to verify and add new
Do CI environments present stdout to the build process as not-a-terminal or as a terminal? I seem to remember seeing "interactive"-style progress indicators twirling around in the log output of running GitLab CI jobs.
FWIW, most (but not all) CI runners set
true by default, if having different default behavior on CI is important.
Behold, the CI for
git-workarea. You can check the blame there too; been using it for years . Then again, I'm someone who lives and breathes build systems (CMake developer; I'm also aware of your role in the
autoconf stack)…I vastly prefer the defaults to be "summary by default, but easy to ask for verbosity". I've had to field way too many reports where the wrong part is focused on/provided because the "real" problem is lost in a sea of output and many developers' "this looks like the problem" detectors are…not great for build system issues (spurious messages are too common and very distracting).
This sounds like a better thing to key on than "output is a TTY" because:
- editors which launch builds tend not to forward a full-featured TTY;
- when debugging CI locally, behaving like CI is very important (rather than faffing about trying to figure out how to convince tools to behave like they do "in the cloud");
- logging to files in CI and locally are both common enough (for me at least) because CI logs have size limits after which they just stop listening (GitLab-CI) or I want to shuttle output to outside of the container (e.g., shimming in a
:makcommand to "reproduce" the warnings in a useful development environment for guided fixing).
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.