View previous topic :: View next topic |
Show or hide build output by default? |
emerge should hide build output by default (unless --quiet-build=n) |
|
28% |
[ 135 ] |
emerge should show build output by default (unless --quiet-build=y) |
|
51% |
[ 240 ] |
The -v option should control whether build output is shown or not by default |
|
17% |
[ 81 ] |
Other (please comment) |
|
2% |
[ 10 ] |
|
Total Votes : 466 |
|
Author |
Message |
Hrk Tux's lil' helper
Joined: 24 May 2003 Posts: 90 Location: Rome, Italy
|
Posted: Mon Nov 14, 2011 6:16 pm Post subject: |
|
|
My opinion (and thusly my vote) is that emerge should show the build output by default, as it has been in the past.
Before voting, however, I tried the quiet output on a compile and load averages were so slow to update that I thought the process was stuck.
Since the option enables people to hide the output, I consider this as a matter of "changing for the sake of changing" which gets a BIG[1] NO from me.
[1] 0.02c big. |
|
Back to top |
|
|
Voyageur Developer
Joined: 06 Mar 2005 Posts: 342 Location: Paris, France
|
Posted: Mon Nov 14, 2011 6:17 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
th9 n00b
Joined: 07 Mar 2008 Posts: 8
|
Posted: Mon Nov 14, 2011 6:34 pm Post subject: |
|
|
Voted for hide by default.
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. |
|
Back to top |
|
|
firephoto Veteran
Joined: 29 Oct 2003 Posts: 1612 Location: +48° 5' 23.40", -119° 48' 30.00"
|
Posted: Mon Nov 14, 2011 6:41 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54323 Location: 56N 3W
|
Posted: Mon Nov 14, 2011 7:00 pm Post subject: |
|
|
I voted hide by default.
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. |
|
Back to top |
|
|
Randy Andy Veteran
Joined: 19 Jun 2007 Posts: 1148 Location: /dev/koelsch
|
Posted: Mon Nov 14, 2011 7:11 pm Post subject: |
|
|
Hi Geeks.
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! |
|
Back to top |
|
|
marens Apprentice
Joined: 05 Aug 2004 Posts: 173
|
Posted: Mon Nov 14, 2011 7:15 pm Post subject: |
|
|
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! |
|
Back to top |
|
|
Hwoarang Retired Dev
Joined: 24 Feb 2007 Posts: 701 Location: Leeds, UK
|
Posted: Mon Nov 14, 2011 7:16 pm Post subject: |
|
|
The questions are wrong:
emerge should show build output by default (unless --quiet-build=y) instead of "n"
Same thing for the other question |
|
Back to top |
|
|
Etal Veteran
Joined: 15 Jul 2005 Posts: 1931
|
Posted: Mon Nov 14, 2011 7:26 pm Post subject: |
|
|
Randy Andy wrote: |
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 |
|
Back to top |
|
|
thumper Guru
Joined: 06 Dec 2002 Posts: 552 Location: Venice FL
|
Posted: Mon Nov 14, 2011 7:30 pm Post subject: |
|
|
I prefer hide by default, but as long as I can switch it either way I'm happy whatever way you guys need to go.
George |
|
Back to top |
|
|
non7top n00b
Joined: 17 Dec 2008 Posts: 16
|
Posted: Mon Nov 14, 2011 7:41 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
non7top n00b
Joined: 17 Dec 2008 Posts: 16
|
Posted: Mon Nov 14, 2011 7:43 pm Post subject: |
|
|
Etal wrote: | you see the same exact thing whether you use the old behavior or the new. |
not completely true, for instance cmake colors will be lost. |
|
Back to top |
|
|
Etal Veteran
Joined: 15 Jul 2005 Posts: 1931
|
Posted: Mon Nov 14, 2011 9:54 pm Post subject: |
|
|
non7top wrote: | Etal wrote: | you see the same exact thing whether you use the old behavior or the new. |
not completely true, for instance cmake colors will be lost. |
Oddly enough, this whole thing started with this message:
Quote: | 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 |
|
Back to top |
|
|
keenblade Veteran
Joined: 03 Oct 2004 Posts: 1087
|
Posted: Mon Nov 14, 2011 11:15 pm Post subject: |
|
|
avx wrote: | voted: hide by default
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:
Code: |
FEATURES="noisy-build" emerge -va blabla
lots of output here
|
_________________ Anyway it's all the same at the end...
Need help to get it working: "x-fi surround 5.1" |
|
Back to top |
|
|
firephoto Veteran
Joined: 29 Oct 2003 Posts: 1612 Location: +48° 5' 23.40", -119° 48' 30.00"
|
Posted: Mon Nov 14, 2011 11:29 pm Post subject: |
|
|
keenblade wrote: |
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 |
|
Back to top |
|
|
peter4 Guru
Joined: 19 Jul 2005 Posts: 359 Location: Wroclaw, Poland
|
Posted: Mon Nov 14, 2011 11:43 pm Post subject: |
|
|
I voted to keep the old behaviour. Some packages (CMake) show build completion percentage in the output, which can be quite useful. |
|
Back to top |
|
|
ppurka Advocate
Joined: 26 Dec 2004 Posts: 3256
|
Posted: Tue Nov 15, 2011 2:04 am Post subject: |
|
|
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 kde5 | e is unstable :-/ |
|
Back to top |
|
|
teika Apprentice
Joined: 19 Feb 2011 Posts: 155 Location: YYYY-MM-DD, period. Have you ever used the Internet?
|
Posted: Tue Nov 15, 2011 2:12 am Post subject: |
|
|
Opinions alone here don't seem to converge.
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)
With best regards. _________________ Hack of easy Shift / Ctrl / AltGr etc; save your pinkies, type without drudgery: topic 865313
XPAT - Xi, Putin, Abe and Trump - are security holes of their own nations.
Last edited by teika on Tue Nov 15, 2011 3:23 am; edited 1 time in total |
|
Back to top |
|
|
fastijum n00b
Joined: 29 Aug 2009 Posts: 5
|
Posted: Tue Nov 15, 2011 2:14 am Post subject: |
|
|
Voted for hide by default.
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.
Just sharing my thoughts on the subject. |
|
Back to top |
|
|
codestation Tux's lil' helper
Joined: 09 Nov 2008 Posts: 126 Location: /dev/negi
|
Posted: Tue Nov 15, 2011 4:12 am Post subject: |
|
|
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... |
|
Back to top |
|
|
miket Guru
Joined: 28 Apr 2007 Posts: 488 Location: Gainesville, FL, USA
|
Posted: Tue Nov 15, 2011 4:39 am Post subject: Keep the build log |
|
|
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. |
|
Back to top |
|
|
pappy_mcfae Watchman
Joined: 27 Dec 2007 Posts: 5999 Location: Pomona, California.
|
Posted: Tue Nov 15, 2011 5:08 am Post subject: |
|
|
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.
Cheers,
Pappy _________________ This space left intentionally blank, except for these ASCII symbols. |
|
Back to top |
|
|
th9 n00b
Joined: 07 Mar 2008 Posts: 8
|
Posted: Tue Nov 15, 2011 5:32 am Post subject: |
|
|
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. |
|
Back to top |
|
|
wthrowe Tux's lil' helper
Joined: 19 Aug 2009 Posts: 141
|
Posted: Tue Nov 15, 2011 5:53 am Post subject: |
|
|
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. |
|
Back to top |
|
|
xaviermiller Bodhisattva
Joined: 23 Jul 2004 Posts: 8710 Location: ~Brussels - Belgique
|
Posted: Tue Nov 15, 2011 8:01 am Post subject: |
|
|
Hello,
I voted to show the output by default.
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 |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|