[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs

On 13 August 2013 19:59, Julien Cristau <jcristau@debian.org> wrote:
> [why oh why are you breaking threading?]
> On Tue, Aug 13, 2013 at 19:51:52 +0200, Dmitrijs Ledkovs wrote:
>> We have build log analyzers running for the build logs. And the
>> important compiler warnings (errors) fail the build.
>> If we make this opt-in, we will fail to achieve this goal. As when one
>> is debugging a failed build (e.g. the failure in the last hour of
>> webkit/qt/libreoffice compile on armhf porter box, or by hand
>> ./debian/rules build) that's when one would start caring & wishing to
>> have the verbose output would have been set, but it would be too late.
> I don't see how.  Either dpkg-buildpackage -nc or re-running
> debian/rules build with the option set would give you what you want.

For well behaved build-systems that would only show flags for the yet
to compile object, where the bug might be in the flags/libs used for
the already compiled objects. (i don't have an example here, something
like mixing with/without -fPIC but we get warnings which objects are
at fault anyway)

For less behaved build-systems this may cause a reconfigure and
restart the whole build. Which is suboptimal.

In the past there have been random bugs / build failures which are not
reproducible on re-runs (but I've yet to see one which depended on
build-flags, unless one gets different flags =/ on reruns which
wouldn't know about....)

In controlled environments, one doesn't get to re-run a build, as the
instances are stripped-down and destroyed on build failure E.g. all
the jenkins instances running debian package builds, PPAs,
auto-package-tests, automated cross-builders. One would have to modify
each and every deployment of those...

Somehow we lived fine with verbose build-logs, until automake silent
rules and a few other build-systems started to become more silent. I
can understand the appeal of silent builds for upstream developers,
but it makes zero sense for a distribution or package maintainers or
our downstream.



Reply to: