Re: "make check" changes have caused buildfarm deterioration.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: "make check" changes have caused buildfarm deterioration.
Дата
Msg-id 28583.1437487256@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: "make check" changes have caused buildfarm deterioration.  (Andrew Dunstan <andrew.dunstan@pgexperts.com>)
Ответы Re: "make check" changes have caused buildfarm deterioration.  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Andrew Dunstan <andrew.dunstan@pgexperts.com> writes:
> On 07/21/2015 01:39 AM, Michael Paquier wrote:
>> Regarding install.log, the use of stdout/stderr instead of a log file
>> has been changed in dbf2ec1a after that:
>> http://www.postgresql.org/message-id/553FE7FC.2040707@gmx.net
>> Since 9.5 as the location of the temporary installation is global, we
>> could basically revert some parts of dcae5fac if that helps so as
>> install.log is saved in $ROOT/tmp_install/log/install.log... But I am
>> not sure what we win with that, and the argument to remove install.log
>> is that now the temporary installation is a make target. Both ways
>> have advantages and disadvantages.

> I'm quite unhappy about how we now pollute the output of "make check" 
> with the install log. See the above links for why. And when I run it by 
> hand I don't want all this scrolling by me on the screen. The previous 
> output of "make check" was small and clean, and I want it to go back to 
> that, with the other logs available as necessary. The reason the 
> buildfarm client cd's into the regress directory to run "make check" is 
> to avoid extraneous output.

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.

A possible alternative is to run the "make install" sub-step with -s,
but that could be objected to on the grounds that if it did fail, you'd
have a hard time telling exactly which step failed.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: creating extension including dependencies
Следующее
От: Teodor Sigaev
Дата:
Сообщение: Re: Selectivity estimation for intarray with @@