Re: "make check" changes have caused buildfarm deterioration. - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: "make check" changes have caused buildfarm deterioration.
Date
Msg-id CAMkU=1zSZT2ebtHmxKgZPYgEXT_TBO0jUzZ5ohb5C5adddqp1g@mail.gmail.com
Whole thread Raw
In response to Re: "make check" changes have caused buildfarm deterioration.  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: "make check" changes have caused buildfarm deterioration.
List pgsql-hackers
On Tue, Jul 21, 2015 at 6:31 PM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Wed, Jul 22, 2015 at 10:04 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On 7/21/15 10:00 AM, Tom Lane wrote:
>> I agree; this change may have seemed like a good idea at the time, but
>> it was not.  Failures during "make check"'s install step are rare enough
>> that you don't really need all that output in your face to help with the
>> rare situation where it fails.  And for the buildfarm's purposes, it is
>> surely desirable to segregate that output from the actual check step.
>
> It wasn't really an idea; it was just not necessary anymore.  We can put
> it [directing the make install output into a file] back if that's what
> people prefer.

OK... Attached are two patches (please merge them into a single
commit, I am just separating them as they are separate issues):
- 0001 adds a missing entry in test_ddl_deparse's .gitignore. I
mentioned that upthread.
- 0002 redirects the installation logs into
abs_top_builddir/tmp_install/log/install.log. We could redirect it
only to abs_top_builddir/log/ but tmp_install is not removed after a
run of a regression make target.

If I run 'make check' on an unbuilt tree, any compiler warnings emitted during the build phase now get directed into the install log.  Was that intentional or a side effect?

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: REVOKE [ADMIN OPTION FOR] ROLE
Next
From: Robert Haas
Date:
Subject: Re: Proposing COPY .. WITH PERMISSIVE