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