1 |
Excerpts from Thomas Sachau's message of 2011-11-13 13:39:17 +0100: |
2 |
> This can be argued from either side, if the default is verbose, you |
3 |
> can make it quiet in the default emerge opts and the other way round. |
4 |
> So this is no argument for or against default quiet build in my eyes. |
5 |
|
6 |
Not every user studies manpages of every program they use. Making |
7 |
--quiet-build=y default is a *benefit* for people who don't care much. |
8 |
If somebody cares about the output probably will care to read the |
9 |
manpage how to make it verbose. How many emerge users know that option? |
10 |
|
11 |
|
12 |
> As already said, it is nice to see, where a build hangs, when some |
13 |
> specific task does take longer and until now, it was easy to see, just |
14 |
> watch the output. With the new default, you cannot say, what it does, |
15 |
> where it may be or if there are many things or just one line taking |
16 |
> much time. And you additionally have to go to the build.log manually |
17 |
> to actually see something. |
18 |
|
19 |
Build output tells almost nothing about the progress (except of cmake). |
20 |
Many packages compile in few minutes on average machine. I hardly ever |
21 |
experience hangs and if - it's usually for boost. For those few |
22 |
packages it's no harm to check build.log. |
23 |
|
24 |
But --quiet-build=y actually gives more useful and handy info: what is |
25 |
a total progress. Which user cares about which module is actually being |
26 |
compiled? He/she cares more which package out of total is being |
27 |
compiled at the moment. |
28 |
|
29 |
|
30 |
> In addition, it is also nice to just a quick look into the console to |
31 |
> see, what and where it failed. |
32 |
|
33 |
When it fails, it prints tail of build.log. |
34 |
|
35 |
|
36 |
-- |
37 |
Amadeusz Żołnowski |