| 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 |
Archives