Andrew Dunstan <andrew.duns...@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.2040...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
