1 |
On Sun, 21 February 2010 Fabian Groffen <grobian@g.o> wrote: |
2 |
> I recently proposed to enable this by default for cmake, but got some |
3 |
> negative feedback for that. Hence, I'd like to know the opinion of |
4 |
> more people on the issue. |
5 |
> |
6 |
> In the past we have had verbose build systems, that printed a lot of |
7 |
> messages. Portage even analyses this output to look for common |
8 |
> problems. Newer buildsystems (like cmake), or just newer insights |
9 |
> (like gnustep makefiles, linux kernel, git, ...) suppress more |
10 |
> messages leading to reduced output. |
11 |
> |
12 |
> - should we leave defaults of build systems as is, keeping some very |
13 |
> verbose and others very terse? |
14 |
> - should we always enable verbosity such that we can analyse logs, |
15 |
> both by Portage as well as in bugs when something apparently went |
16 |
> wrong? |
17 |
> - should make the output level consistent for all build systems? |
18 |
> |
19 |
> I think verbosity is useful when debugging problems. Portage's --jobs |
20 |
> feature nicely allows to hide the "ugly" output (even with --jobs=1), |
21 |
> still storing the log for when something goes wrong, while eliminating |
22 |
> the need to look at it all the time. |
23 |
> |
24 |
> So what do you think? Pros, cons? |
25 |
|
26 |
IMHO the ideal solution would be to allow build-systems to be terse for |
27 |
successful operations but print the full command of the failing ones. |
28 |
That is, they would have to buffer output and show it only if the |
29 |
command failed. (they probably already have to buffer if parallel build |
30 |
should output consistent information) |
31 |
|
32 |
But this has probably to be solved on a larger scale than just Gentoo. |
33 |
|
34 |
Bruno |