Thankfully there is EMERGE_DEFAULT_OPTS to disable this quiet mode, which is sadly useless as it is right now

Wit this use case: standard desktop, emerge jobs set to 1 (default), what is the usefulness of displaying load average (useless for one job, and probably irrelevant because of firefox or other program hogging the CPU), and a counter on current packages done (23 of 94: not really useful)

What would be useful: restore package currently compiling name (more useful info, and will display in terminal window title bar, same as it was before), terminal activity (spinner or whatever) to show that something is going on (basic ergonomy), and maybe display current phases (aka "is it sill compiling or almost done?")

To sum up, it would have been nice to stop and think 5 minutes on what is useful for standard "quiet" output, and not just re-use the multiple jobs one_________________Routinely breaking NX, GNUstep, net-ftp, miscellaneous (llvm, filezilla, rdesktop, chromium, ...) packages

Last edited by Voyageur on Wed Nov 16, 2011 3:52 pm; edited 1 time in total

Most of that information is never useful anyway and if I get really bored I can turn it on. One might argue about reading the elog messages, but most of them are usually out of buffer anyway so using elogv is better and there might be an option to dump them at the end..

With parallel make and emerge it is completely useless for me.

Emerge could have an option to add a spinner there for people who can't see if the machine has hanged from changing load numbers.

Since one of the big reasons for Gentoo is to build the system it only makes sense to show the building process by default. Even if it isn't accurate due to other decisions to suppress certain output it gives the user a sense that something is going on. If some people want to suppress the output the option is there but to have the default output such a limited set of information and most likely useless information to most users (loadavg? really?) it's not very intuitive and quiet-build isn't very relevant to what it actually suppresses.

Proposal, make quiet-build do just that, suppress just the actual compilation output, show what gets configured if that applies, show where files are going or a condensed output that shows installation location of executables and configurations or documentation, show something is being downloaded... Just don't kill it all in the name of colored text and multi-cpu out of order output polluting build failure reports (which somehow started this on the -dev discussion).

It outputs specifics when the builds fail and that location is know, it's not that hard to do something for the user that makes uploading that failure log easier unless the desire is to not make these things easier. Make things better for the user, not just higher walls so he can't get outside the box as easy._________________#gentoo-kde on freenode

Once upon a time, I could read the build output as it was generated. That was in 2002 when I did my first install on a k6-2 450MHz system.
As successive systems have got faster, its become more and more difficult to read, (read more and more useless).

Since I built a multi-core box a few years ago, the output was gone for me anyway, as I use --jobs almost all the time.

Its time to move with the times - increasing hardware speeds makes the console output useless, so its time to default it to off.
By all means document in the handbook how to turn console build messages on but only so new users can appreciate the history if they decide they want to._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

I voted to maintain the old behavior (defaulting to --quiet-build=n) too.

My personal pros and cons:

Pros:
- It's the know behavior by all gentoo users, changing it confuses lots of them as we see in lots of newly discussions.
If it wasn't the default for years, lots of us doesn't know it and like it, as lots of us do. Some users gave statements in the past that they sometimes like watching the compiling output just for fun.
- The new default is boring. Ok, we can switch it, but how did we know this, if it was default for Years.

- Watching the compiling output can give the experienced user some needful information. E.g. for distcc users:
# Did you forget to run emerge in pump mode?
or if you don't use the pump mode, you can see if the helping machines are working, otherwise you get a hint like this:
# distcc machine not reachable, compiling locally instead.

- Compiling output is very geeky and totally different to all other install messages of binary distros.
- It's nearly an unique feature which shows all new users how compiling works on this outstanding distribution. It has a little to do with marketing, so don't hide it from the uninformed user.
Instead of hiding it, let us make it more geeky. I prefer to let it flow vertical in green letters like the uncoded Matrix, as a new Option called M (defaulting to --quiet-build=M)

- For someone its magically to watch how the distribution compiles itself from the sources automatically.

- On very slow machines, where it takes about a day to compile gcc, it is very helpful to see that it does what it should and didn't crashed.
- If a build crashes, we have already the relevant output on the screen, mostly no need to look into the fully build log or build environment.

Cons:
- Little lower performance cause the output.

My opinion
regarding the results of the voting: I guess the guys who voted for the verbose switch tends more to the old standard behavior, if the -v option is used.
One more reason for me to switch back, cause it seems to be the majority of users, who wants the old behavior.

Best regards, Andy._________________If you want to see a Distro done right, compile it yourself!

Hide by default. Portage even prints the url of the logfile when a package fails so it's just a matter of copy and paste to view the full logfile._________________If English was good enough for Jesus, then it's good enough for you!

Pros:
...
- If a build crashes, we have already the relevant output on the screen, mostly no need to look into the fully build log or build environment.

A lot of people seem to be missing that if the build crashes, it dumps the build.log, so in the end, you see the same exact thing whether you use the old behavior or the new._________________“And even in authoritarian countries, information networks are helping people discover new facts and making governments more accountable.”– Hillary Clinton, Jan. 21, 2010

There is already "-v" and "-q" options. Why introduce another "more verbose", "and a bit more more verbose" all with different non-obvious names? At least it could be an ssh approach "-vv", the more v the more verbose. I can't understand how it happens that when "--verbose" option is explicitly set, portage decides to not be verbose and hide all output instead.
Voting for "The -v option" or at least "emerge should show" as it is there for ages.

Hi,
I'd like to ask that we enable verbose building by default. I have
cmake-utils.eclass in mind, because it's dead easy there, but there's a
lot of packages that support things like "make V=1" or "make VERBOSE=1" too.

I've seen too many bugs reports today that gave me cute, colorful
build.logs and almost no information about underlaying bug...
Cheers,
Kacper

_________________“And even in authoritarian countries, information networks are helping people discover new facts and making governments more accountable.”– Hillary Clinton, Jan. 21, 2010

I've got it turned off for a long time, mainly because it dramatically slows down the built when on VT (yeah, crappy driver). Unless something fails, I won't need it and in that case, there's still the .log.

No to binding it to -v, confusing for me.

+1
Hide by default. And using a FEATURES "noisy-build" in make.conf keeps old behavior. So, something like this will keep old behavior easily, if wanted for particular emerges:

Hide by default. And using a FEATURES "noisy-build" in make.conf keeps old behavior. So, something like this will keep old behavior easily if wanted for particular emerges:

Code:

FEATURES="noisy-build" emerge -va blabla
lots of output here

I think that's where this becomes confusing for some since there is actually a --quiet-build emerge command option which you'll only see in the man page and not from --help or bashcomp. There are literally dozens of 'new to me' things I just discovered by looking at the man page which I'm pretty sure weren't in there the last time I was digging through it to do something unusual._________________#gentoo-kde on freenode

Seeing all these build output scroll by is pretty useless. One gains absolutely nothing by looking at a bunch of gcc lines scrolling by, unless (s)he is a dev or a curious user of that software. On a non-accelerated tty it will also take up more cpu trying to scroll by this enormous chunk of output. This is one of the reasons why I always build with -q (and made a script to do it automatically).

Voted for the first option. It is a much needed default._________________emerge --quiet redefined | E17 vids: I, II | Now using e17 | e18, e19, and kde4 sucks :-/

I prefer not to waste our time, so I'd like:
* Close this disucssion soon, whichever the conclusion.
* I think it'll make less noise by sticking to the previous behavior
* Let users remember that you can add --quiet-build=y to EMERGE_DEFAULT_OPTS in /etc/make.conf.
* -v is completely wrong. Maybe new short options -qby / -qbn suffice.
* When you set PORT_LOGDIR, it's flooded. It might be nice if a symlink "last.log-[123...]" (or failure.log) be generated, so that it'd suffice to do "less last.log*". (I'd like some refinement in PORT_LOGDIR, but it's offtopic here. =P)

On my mid-end Core 2 the output is too fast anyway, and in case of failure emerge prints the full path, ready for sudo less <paste>. Also, I believe that all that output wastes some CPU, in a time when any clock cycle can be useful.

While CMake does output a neat progress percentage (wish GNU make did, too), it’s only used by very few projects (on my dev system, almost 800 packages, only 14 use CMake), so I don’t consider it any significant.

Plus, let’s not forget that it’s trivial to add the --quiet-build=n option to emerge.

For me any of the 2 first options are fine since its only a switch that one can put into EMERGE_DEFAULT_OPTS (like the --keep-going). Totally aganist the 3rd option since it changes the meaning of the -v switch (show the USE flags when -p or -a is used).

Voted for showing output by default since i have lots of packages that use cmake like KDE, Qt and lots of other apps that uses this build system. Its always nice to have a completion value when looking at the terminal window so i can have a rough estimate of the remaining compilation time._________________Just feel the code...

I am in favor of the current behavior for most of the reasons mentioned so far: indication of progress, knowlege of what files are being installed, place to look to find what went wrong in a build that failed (VERY valuable), and an indication that something is happening. To these I add these insights I gain: an indication of what build system a project uses, an idea of which source files take a long time to compile, and all those funny little compiler warnings the maintaners chose to ignore.

Also, the -v switch has a very well known and documented use, and this is completely unrelated to the verbosity of the compiler output. Leave -v alone.

I've used the -v option from day one. I don't see why it was necessary to change this, even with all that people have said. I also get the feeling this was a change made because it could be, not because it was in any way needed. If I wanted the addition of new packages to be silent, I would have installed a binary distro, not one that makes my system for me while I watch.

Yes, machines are getting faster daily, but that doesn't mean myself and others can't keep up with that which flies past the screen. There have been many times that the behavior of the output was more telling than the final error(s) that stopped certain packages from compiling.

I also do a bit of ebuild hacking. That means I really, REALLY want to know what's going on with my "repaired" ebuilds. Not having the output in that situation is totally unacceptable.

I am a bit confused by those who claim it's so hard to turn on the -v switch. This is Linux. When you get the command the way you want it, you hit the "up" arrow until that command pops up, hit enter, and you're on your way. If you want, you can even edit ~/.bash_history to fix any errors with the command. How can that be even slightly construed as hard, difficult, or whatever? I don't get that in the least.

I see that many people don't realize that this all question rose because devs would like to make build systems (including CMake) verbose by default to get more useful bug reports from users. When that is done all your nice, colorful CMake output is trashed anyway, because full build commands are printed, which are very long and pretty useless for everyday use.

When a package fails emerging with quiet build, all its build log is dumped in terminal so you see right away what happened.

Naming of the options is irrelevant to the main question and should have been kept for other discussion.

I agree that --quiet-build option should be advertised more (as should EMERGE_DEFAULT_OPTS). I was setting -s in MAKEOPTS exactly for the reason that the build output was too verbose for normal use. Was very happy when discovered --quiet-build option. Now I have set quiet build for some time, but when debugging a package or testing ebuild I'm switching that option to see all the fun details. Works great.

Also for world updates I like to see how far it has got in terms of the emerged packages, not every individual package. Having the list of packages to emerge with all version and use flag info (-av) and the list of packages already done, that is useful.

I voted for it to be shown. It doesn't matter much to me personally, because it is easy to set in make.conf, but new users won't go looking for a way to turn on something they don't know exists. If the default had been for silent builds when I started using Gentoo, that's probably what I would be using.

Why does this matter? Because I have spotted bugs in the build output scrolling past (not everyone runs Gentoo on the latest and greatest hardware). For example, particularly for some simpler build systems, it's not hard to see that your CFLAGS are being overridden. You can also spot cases where someone has accidentally used einfo instead of elog when you see a postinstall message go past that isn't in the summary at the end.

The output is useful and it encourages users to get more involved by filing bugs or asking about it on the forum.

As developer, I like to see what is happening, and this emerge outputs shows me as a Geek to other people

A good point could be that the Make process should behave like CMake, with a progress bar, and a simple list of what is compiled (not the full gcc --with-all-options). But this work is for upstream._________________Kind regards,
Xavier Miller