| 1 |
Hi all, |
| 2 |
|
| 3 |
Inspired by the recent poppler move from autoconf to cmake for its |
| 4 |
build system, the following. |
| 5 |
|
| 6 |
Given that poppler didn't compile on at least two arches, I found that |
| 7 |
cmake is pretty much terse in its output, especially when errors are |
| 8 |
encountered. Often it is important to know how the compiler or linker |
| 9 |
was invoked, to be able to (quickly) resolve the issue at hand. Cmake |
| 10 |
doesn't seem to report such call by default, it needs VERBOSE=1 to be |
| 11 |
set in the environment in order to do so. |
| 12 |
|
| 13 |
I recently proposed to enable this by default for cmake, but got some |
| 14 |
negative feedback for that. Hence, I'd like to know the opinion of more |
| 15 |
people on the issue. |
| 16 |
|
| 17 |
In the past we have had verbose build systems, that printed a lot of |
| 18 |
messages. Portage even analyses this output to look for common |
| 19 |
problems. Newer buildsystems (like cmake), or just newer insights (like |
| 20 |
gnustep makefiles, linux kernel, git, ...) suppress more messages |
| 21 |
leading to reduced output. |
| 22 |
|
| 23 |
- should we leave defaults of build systems as is, keeping some very |
| 24 |
verbose and others very terse? |
| 25 |
- should we always enable verbosity such that we can analyse logs, both |
| 26 |
by Portage as well as in bugs when something apparently went wrong? |
| 27 |
- should make the output level consistent for all build systems? |
| 28 |
|
| 29 |
I think verbosity is useful when debugging problems. Portage's --jobs |
| 30 |
feature nicely allows to hide the "ugly" output (even with --jobs=1), |
| 31 |
still storing the log for when something goes wrong, while eliminating |
| 32 |
the need to look at it all the time. |
| 33 |
|
| 34 |
So what do you think? Pros, cons? |
| 35 |
|
| 36 |
|
| 37 |
-- |
| 38 |
Fabian Groffen |
| 39 |
Gentoo on a different level |
Archives