| 1 |
Am Sonntag, den 21.02.2010, 19:36 +0100 schrieb Fabian Groffen: |
| 2 |
> Hi all, |
| 3 |
> |
| 4 |
> Inspired by the recent poppler move from autoconf to cmake for its |
| 5 |
> build system, the following. |
| 6 |
> |
| 7 |
> Given that poppler didn't compile on at least two arches, I found that |
| 8 |
> cmake is pretty much terse in its output, especially when errors are |
| 9 |
> encountered. Often it is important to know how the compiler or linker |
| 10 |
> was invoked, to be able to (quickly) resolve the issue at hand. Cmake |
| 11 |
> doesn't seem to report such call by default, it needs VERBOSE=1 to be |
| 12 |
> set in the environment in order to do so. |
| 13 |
> |
| 14 |
> I recently proposed to enable this by default for cmake, but got some |
| 15 |
> negative feedback for that. Hence, I'd like to know the opinion of more |
| 16 |
> people on the issue. |
| 17 |
> |
| 18 |
> In the past we have had verbose build systems, that printed a lot of |
| 19 |
> messages. Portage even analyses this output to look for common |
| 20 |
> problems. Newer buildsystems (like cmake), or just newer insights (like |
| 21 |
> gnustep makefiles, linux kernel, git, ...) suppress more messages |
| 22 |
> leading to reduced output. |
| 23 |
> |
| 24 |
> - should we leave defaults of build systems as is, keeping some very |
| 25 |
> verbose and others very terse? |
| 26 |
> - should we always enable verbosity such that we can analyse logs, both |
| 27 |
> by Portage as well as in bugs when something apparently went wrong? |
| 28 |
> - should make the output level consistent for all build systems? |
| 29 |
> |
| 30 |
> I think verbosity is useful when debugging problems. Portage's --jobs |
| 31 |
> feature nicely allows to hide the "ugly" output (even with --jobs=1), |
| 32 |
> still storing the log for when something goes wrong, while eliminating |
| 33 |
> the need to look at it all the time. |
| 34 |
> |
| 35 |
> So what do you think? Pros, cons? |
| 36 |
> |
| 37 |
|
| 38 |
Please always enable verbose (as in "show the actual gcc command line |
| 39 |
call") output unless a build system shows the complete call in case it |
| 40 |
failed. |
| 41 |
Being able to attach the build log without the need to first rerun the |
| 42 |
merge process with some flag set to get the full output is easier for |
| 43 |
the user and therefore a good thing. |
| 44 |
Leave the output mangling to the package manager. |
| 45 |
|
| 46 |
Cheers, |
| 47 |
Tiziano |
| 48 |
|
| 49 |
-- |
| 50 |
Tiziano Müller |
| 51 |
Gentoo Linux Developer |
| 52 |
Areas of responsibility: |
| 53 |
Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor |
| 54 |
E-Mail : dev-zero@g.o |
| 55 |
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 |
Archives