Build log should _always_ be verbose. This is not about build output which is controled by --quiet-build. Reasons: 1. I want to see what happens. The build system might ignore CFLAGS, LDFLAGS (-Wl,--hash-style=gnu is not default) or add other random things. 2. When I ask someone in #gentoo to show me the build log I have to tell him he gotta recompile with EXTRA_ECONF="--disable-silent-rules" or whatever, because I often cannot help with non-verbose build log. The same goes for attached build logs on bugzie. Solution: 1. When using cmake just make sure to call "cmake-utils_src_compile", because CMAKE_VERBOSE is ON by default. For games ebuilds you have to overwrite src_compile function with this, because otherwise base_src_compile will be carried out. 2. For autotools based build systems add --disable-silent-rules to econf. 3. Custom Makefiles might need a patch.
Reason 3: some QA checks might depend on verbose build log and are not yet implemented therefor.
Solution 2 will be obsolete as per http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=1cc39de72ac5311db748341ef9183586556719d9
Solution 2 is not obsolete and the portage fix has been reverted until we get some council decision on this.
note for autotools based build systems: --disable-silent-rules is now part of econf in EAPI=5
Interesting. I always want to see verbose build log disabled :] I'd appreciate an output for mc-9999 or xmms2-9999 in human-readable form, not those pages of the same flags to notice newly popped suspictions on my platform (-Werror is too harsh though) [CC] foo.o Here go only warnings reported by compiler and not 8 lines of include directories and unrelated -Woptions What is the generic way to actually disable that verbose output for a single run for a random package? For xmms2 (waf based) case verbose build log will look rather weird (i did run ./waf configure, thus varuables are used by default, not gentoo-ish): [ 40/348] c: src/plugins/vocoder/pvocoder.c -> _build_/src/plugins/vocoder/pvocoder.c.1.o 00:19:29 runner ['/usr/bin/gcc', '-g', '-O0', '-Wall', '-Wempty-body', '-Wformat=2', '-Wformat-nonliteral', '-Wformat-security', '-Wignored-qualifiers', '-Wmissing-prototypes', '-Wstrict-prototypes', '-Wtype-limits', '-Wwrite-strings', '-Wno-format-extra-args', '-Wno-format-zero-length', '-fdiagnostics-show-option', '-Werror=implicit-function-declaration', '-fPIC', '-I/tmp/portage/media-sound/xmms2-0.8-r1/work/xmms2-0.8DrO_o/_build_', '-I/tmp/portage/media-sound/xmms2-0.8-r1/work/xmms2-0.8DrO_o', '-I/tmp/portage/media-sound/xmms2-0.8-r1/work/xmms2-0.8DrO_o/_build_/src/include', '-I/tmp/portage/media-sound/xmms2-0.8-r1/work/xmms2-0.8DrO_o/src/include', '-I/usr/include/glib-2.0', '-I/usr/lib64/glib-2.0/include', '../src/plugins/vocoder/pvocoder.c', '-c', '-o', 'src/plugins/vocoder/pvocoder.c.1.o'] I don't expect any sane QA on such output. QA-wise inserting canary into CFLAGS (like -frecord-gcc-switches) or setting proper $CC to do the checks sounds more reliable.
Wow what an amazing waste of time. Why didn't you file a single bug for the xorg-2 eclass, wait for it to get fixed, and then see what problems were left before filing 110 identical bugs? Really fricking stupid. The original reporter needs to use his automated filing tool to automatically close these bugs too. I don't want anyone else wasting their time closing 100+ duplicates.
I suggest to only file bugs for non-standard build systems or directly for an eclass. EAPI-controlled build systems (econf) will migrate slowly over time, cause we have the fix in EAPI-5. Eclass-controlled build systems (such as cmake) can be solved on an eclass level. Custom Makefiles often need a patch and it's a good thing to report them.
the devmanual has been patched to reflect the input of the dev community http://git.overlays.gentoo.org/gitweb/?p=proj/devmanual.git;a=commit;h=b373edb4fbb2f619b0f153985a9e1b5d8c8f3220 to rephrase this a bit: Bugs should be filed... * if the build system does not use econf or something conrollable by an eclass (such as cmake or games). Otherwise we assume that ebuilds migrate to EAPI=5 over time which solves this anyway. * for the eclass that controls the build system (e.g. cmake) or the package in another way (e.g. games.eclass or gnome2.eclass) * for a single ebuild if there are no solutions above ebuild-level
