Excerpts from Thomas Sachau's message of 2011-11-13 14:59:57 +0100:
> How is that an argument for default quiet build? It is exactly the
> same argument against default quiet build. If someone does not care,
> he does not care about the output being verbose or not, so no need to
> change a default for him.
As I have written below, information about overall process is more
valuable than some gmake rubbish (to the user) output which slows down
build time. And having that shinny human readable output gives actually
an information to the reader.
> And what does a number of users knowing about an option have to do
> with a default setting?
More user-friendly options should be default, not developer-friendly.
The discussion started with problem, that build.log could be more
verbose, which will clutter users' screen even more.
> You expect people to manually check the build.log just to see, where
> it hangs? I prefer checking the console, there i can see it directly
> and dont have to check for the path of the current build.log and then
> have to additionally open it manually. So your "no harm" is plain
> wrong, since it takes me more time for doing the same thing as before,
> while i still see no benefit for the change of the default.
If you need to watch build output, change defaults. Defaults are for
less experienced users, not for us developers or power users.
> > But --quiet-build=y actually gives more useful and handy info: what
> > is a total progress. Which user cares about which module is
> > actually being compiled? He/she cares more which package out of
> > total is being compiled at the moment.
> If someone does not care about the current state of a compile, he wont
> care about the total state either.
Build output hardly ever says about current state of a compile. If you
can tell from the output how much is left for example for firefox -
> Beside the point, that you can see the total state in the terminal bar
> (i hope, i got the right name for that thing).
This not always work.