public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] Build system output verbosity, e.g. cmake
@ 2010-02-21 18:36 Fabian Groffen
  2010-02-21 19:29 ` Bruno
  2010-02-22 10:00 ` Tiziano Müller
  0 siblings, 2 replies; 3+ messages in thread
From: Fabian Groffen @ 2010-02-21 18:36 UTC (permalink / raw
  To: gentoo-dev

Hi all,

Inspired by the recent poppler move from autoconf to cmake for its
build system, the following.

Given that poppler didn't compile on at least two arches, I found that
cmake is pretty much terse in its output, especially when errors are
encountered.  Often it is important to know how the compiler or linker
was invoked, to be able to (quickly) resolve the issue at hand.  Cmake
doesn't seem to report such call by default, it needs VERBOSE=1 to be
set in the environment in order to do so.

I recently proposed to enable this by default for cmake, but got some
negative feedback for that.  Hence, I'd like to know the opinion of more
people on the issue.

In the past we have had verbose build systems, that printed a lot of
messages.  Portage even analyses this output to look for common
problems.  Newer buildsystems (like cmake), or just newer insights (like
gnustep makefiles, linux kernel, git, ...) suppress more messages
leading to reduced output.

- should we leave defaults of build systems as is, keeping some very
  verbose and others very terse?
- should we always enable verbosity such that we can analyse logs, both
  by Portage as well as in bugs when something apparently went wrong?
- should make the output level consistent for all build systems?

I think verbosity is useful when debugging problems.  Portage's --jobs
feature nicely allows to hide the "ugly" output (even with --jobs=1),
still storing the log for when something goes wrong, while eliminating
the need to look at it all the time.

So what do you think?  Pros, cons?


-- 
Fabian Groffen
Gentoo on a different level



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [gentoo-dev] Build system output verbosity, e.g. cmake
  2010-02-21 18:36 [gentoo-dev] Build system output verbosity, e.g. cmake Fabian Groffen
@ 2010-02-21 19:29 ` Bruno
  2010-02-22 10:00 ` Tiziano Müller
  1 sibling, 0 replies; 3+ messages in thread
From: Bruno @ 2010-02-21 19:29 UTC (permalink / raw
  To: gentoo-dev

On Sun, 21 February 2010 Fabian Groffen <grobian@gentoo.org> wrote:
> I recently proposed to enable this by default for cmake, but got some
> negative feedback for that.  Hence, I'd like to know the opinion of
> more people on the issue.
> 
> In the past we have had verbose build systems, that printed a lot of
> messages.  Portage even analyses this output to look for common
> problems.  Newer buildsystems (like cmake), or just newer insights
> (like gnustep makefiles, linux kernel, git, ...) suppress more
> messages leading to reduced output.
> 
> - should we leave defaults of build systems as is, keeping some very
>   verbose and others very terse?
> - should we always enable verbosity such that we can analyse logs,
> both by Portage as well as in bugs when something apparently went
> wrong?
> - should make the output level consistent for all build systems?
> 
> I think verbosity is useful when debugging problems.  Portage's --jobs
> feature nicely allows to hide the "ugly" output (even with --jobs=1),
> still storing the log for when something goes wrong, while eliminating
> the need to look at it all the time.
> 
> So what do you think?  Pros, cons?

IMHO the ideal solution would be to allow build-systems to be terse for
successful operations but print the full command of the failing ones.
That is, they would have to buffer output and show it only if the
command failed. (they probably already have to buffer if parallel build
should output consistent information)

But this has probably to be solved on a larger scale than just Gentoo.

Bruno



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [gentoo-dev] Build system output verbosity, e.g. cmake
  2010-02-21 18:36 [gentoo-dev] Build system output verbosity, e.g. cmake Fabian Groffen
  2010-02-21 19:29 ` Bruno
@ 2010-02-22 10:00 ` Tiziano Müller
  1 sibling, 0 replies; 3+ messages in thread
From: Tiziano Müller @ 2010-02-22 10:00 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 2364 bytes --]

Am Sonntag, den 21.02.2010, 19:36 +0100 schrieb Fabian Groffen:
> Hi all,
> 
> Inspired by the recent poppler move from autoconf to cmake for its
> build system, the following.
> 
> Given that poppler didn't compile on at least two arches, I found that
> cmake is pretty much terse in its output, especially when errors are
> encountered.  Often it is important to know how the compiler or linker
> was invoked, to be able to (quickly) resolve the issue at hand.  Cmake
> doesn't seem to report such call by default, it needs VERBOSE=1 to be
> set in the environment in order to do so.
> 
> I recently proposed to enable this by default for cmake, but got some
> negative feedback for that.  Hence, I'd like to know the opinion of more
> people on the issue.
> 
> In the past we have had verbose build systems, that printed a lot of
> messages.  Portage even analyses this output to look for common
> problems.  Newer buildsystems (like cmake), or just newer insights (like
> gnustep makefiles, linux kernel, git, ...) suppress more messages
> leading to reduced output.
> 
> - should we leave defaults of build systems as is, keeping some very
>   verbose and others very terse?
> - should we always enable verbosity such that we can analyse logs, both
>   by Portage as well as in bugs when something apparently went wrong?
> - should make the output level consistent for all build systems?
> 
> I think verbosity is useful when debugging problems.  Portage's --jobs
> feature nicely allows to hide the "ugly" output (even with --jobs=1),
> still storing the log for when something goes wrong, while eliminating
> the need to look at it all the time.
> 
> So what do you think?  Pros, cons?
> 

Please always enable verbose (as in "show the actual gcc command line
call") output unless a build system shows the complete call in case it
failed.
Being able to attach the build log without the need to first rerun the
merge process with some flag set to get the full output is easier for
the user and therefore a good thing.
Leave the output mangling to the package manager.

Cheers,
Tiziano

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3551 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-02-22  9:06 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-21 18:36 [gentoo-dev] Build system output verbosity, e.g. cmake Fabian Groffen
2010-02-21 19:29 ` Bruno
2010-02-22 10:00 ` Tiziano Müller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox