Re: Cleaner build output when not much has changed - Mailing list pgsql-hackers

From Gurjeet Singh
Subject Re: Cleaner build output when not much has changed
Date
Msg-id CABwTF4X3_C6FbeHv-yTiRx_URTUS2xtGRtk7tDfOPNHWQ=eDmQ@mail.gmail.com
Whole thread Raw
In response to Re: Cleaner build output when not much has changed  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Cleaner build output when not much has changed  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Tue, Nov 26, 2013 at 12:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Gurjeet Singh <gurjeet@singh.im> writes:
> I was looking for ways to reduce the noise in Postgres make output,
> specifically, I wanted to eliminate the "Nothing to be done for `all' "
> messages, since they don't add much value, and just ad to the clutter.

Why don't you just use "make -s" if you don't want to see that?
The example output you show is not much less verbose than before.

I have a shell function that now adds --no-print-directory to my make command. This patch combined with that switch makes the output really clean (at least from my perspective). Since the use of a command-line switch can be easily left to personal choice, I am not proposing to add that or its makefile-equivalent. But modifying the makefiles to suppress noise is not that everyone can be expected to do, and do it right.


I'm pretty suspicious of cute changes like this to the makefiles.
They too often have unexpected side-effects.  (I'm still pissed off
about having to manually remove objfiles.txt to get it to rebuild a .o
file, for instance.)

You mean the --enable-depend switch to ./configure is not sufficient to force a rebuild on changed source code! With this switch, I have always seen my builds do the right thing, whether I modify a .c file or a .h. I personally have never been forced to remove objfiles.txt to solve a build/make issue. (I primarily use VPATH builds, BTW).

Best regards,

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pre-commit triggers
Next
From: Tom Lane
Date:
Subject: Re: pre-commit triggers