Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setting log level in makefile #194

Closed
jounathaen opened this issue Feb 16, 2019 · 7 comments
Closed

Setting log level in makefile #194

jounathaen opened this issue Feb 16, 2019 · 7 comments
Assignees
Milestone

Comments

@jounathaen
Copy link

Hi, thank you for providing this useful tool!

Background: I personally think that the INFO output of cargo-make is a bit bloated. IMHO Many of the informations would belong in the verbose output.

Features Description
I'd like to set the log-level in the Makefile.toml.
It seems that cargo-make does not read configurations from that file.

Describe the solution you'd like
Make (maybe all) configurations from the config.toml file overrideable in the Makefile.toml file.
Maybe in a [config] section.

@sagiegurari
Copy link
Owner

@jounathaen it has been something I thought about but decided against it.
if you look carefully at the config you would see items which are more of personal preferences.
log level is one of them.

think of a project that some put log level in his makefile as verbose.
your preference is error.
you would get verbose logging all of the time if you worked on that project without the ability to shut it up (unless you put the log level each time in the cli). that could be very frustrating.

that is why i think the machine level configuration in this case is more correct and allows you to personalize your experience without forcing it on others.
makefile configuration section is meant to customize the functionality of the build of the project only which is needed for the build to work correctly.

what do you think?

@jounathaen
Copy link
Author

Hmm, that is a reasonable argument.

But personally, I'm still not happy with the output verbosity at the moment.
I'd prefer, if the default would be a bit less verbose.

This is the output of my cargo make flash command:

[cargo-make] INFO - cargo make 0.16.8
[cargo-make] INFO - Using Build File: Makefile.toml
[cargo-make] INFO - Task: flash
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Setting Up Env.
[cargo-make] INFO - Running Task: init
[cargo-make] INFO - Running Task: build
[cargo-make] INFO - Execute Command: "cargo" "build" "--release"
...

All these information are great, when you have to debug the task, but when the task is run multiple times, this spams the terminal.

My Idea:
Make the default output very slim and make the INFO output only visible when the -v flag is set.
The current output of -v is IMHO a bit too much and could be the output of a --debug flag.
(I can create a new Issue for that).

(Probably you have put more thoughts into this behaviour than me. But for me, the behaviour just feels a bit of, compared to other cargo commands)

@sagiegurari
Copy link
Owner

ok, so the issue is maybe that info shows too much and is closer to verbose than info...
i think that makes sense, but need to think what we want to remove and what to keep.
seeing the command and its output seems like 'info' to me. otherwise you only see step names...
think about cargo build, you see what is downloaded and compiled. only with verbose you see the full rustc command.
so for cargo-make for info you see the command and output, and with verbose you see the actual cargo make step data, conditions and so on...
so i'm not sure what to remove from the info level...

@jounathaen
Copy link
Author

jounathaen commented Feb 17, 2019

ok, so the issue is maybe that info shows too much and is closer to verbose than info...

Yes, that is my impression.

but need to think what we want to remove and what to keep

I think, all information about which files/profiles/env are used belong to verbose output.
(Maybe even the information which task is executed. This is a bit radical, but I have Makefiles in mind, which only print the command output by default.)

My philosopy would be: Assume everything is running as it should run. Then no further output is required. If the user sees that it does not, he can easily investigate by adding -v.

A less radical step would be: Merging information about build file, task, profile, env into a single line.

At the moment, even a simple command: cargo make build outputs 11 lines.

> cargo make build
[cargo-make] INFO - cargo make 0.16.8
[cargo-make] INFO - Using Build File: Makefile.toml
[cargo-make] INFO - Task: build
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Setting Up Env.
[cargo-make] INFO - Running Task: init
[cargo-make] INFO - Running Task: build
[cargo-make] INFO - Execute Command: "cargo" "build" "--release"
    Finished release [optimized + debuginfo] target(s) in 0.02s
[cargo-make] INFO - Running Task: end
[cargo-make] INFO - Build Done  in 0 seconds.

There is even some tasks, which are not defined in my makefile. What I personally would assume as an output is something like:

> cargo make build
[cargo-make] INFO - cargo make 0.16.8
[cargo-make] Running Task: build
    Finished release [optimized + debuginfo] target(s) in 0.02s
[cargo-make] INFO - Build Done  in 0 seconds.

Bonus Question: Why does it print INFO before every command. Isn't every output on the commandline an "info"? 😄

Thanks for discussing my ideas 👍

@sagiegurari
Copy link
Owner

@jounathaen I'll try to clean up the info a bit and move some stuff to debug.
i'm sure it won't be exactly like you hope, but maybe a bit better.

by the way, INFO is not always printed. trying breaking something and you start seeing WARN and ERROR too :)

@sagiegurari
Copy link
Owner

reduced the clutter a bit. still in a dev branch as got few more items to develop before i release it.

@sagiegurari
Copy link
Owner

releasing it today as part of 0.16.9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants