Re: [HACKERS] Shrink volume of default make output
On Mon, Jan 2, 2017 at 03:37:04PM -0600, Jim Nasby wrote: > The recent thread about compiler warnings got me thinking about how it's > essentially impossible to notice warnings with default make output. Perhaps > everyone just uses make -s by default, though that's a bit annoying since > you get no output unless something does warn (and then you don't know what > directory it was in). > > Is it worth looking into this? I'm guessing this may be moot with the CMake > work, but it's not clear when that'll make it in. In the meantime, ISTM > http://stackoverflow.com/a/218295 should be an easy change to make (though > perhaps with a variable that gives you the old behavior). Please src/tools/pgtest for an example of pulling out warning lines and reporting them at the end of the build. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shrink volume of default make output
On 3 January 2017 at 05:37, Jim Nasby wrote: > The recent thread about compiler warnings got me thinking about how it's > essentially impossible to notice warnings with default make output. Perhaps > everyone just uses make -s by default, though that's a bit annoying since > you get no output unless something does warn (and then you don't know what > directory it was in). For that latter reason I'd love to be rid of recursive make. But it's not that bad since we don't have many files of the same names; I just find myself using vim's ctrlp a lot. Personally I'd rather let it lie, use 'make -s' and wait for cmake. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shrink volume of default make output
On 1/2/17 4:37 PM, Jim Nasby wrote: > The recent thread about compiler warnings got me thinking about how it's > essentially impossible to notice warnings with default make output. I always build with -Werror. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Shrink volume of default make output
Jim Nasby writes: > The attached hack doesn't quiet everything, but makes a significant > difference, 1588 lines down to 622, with 347 being make -C (each of > those was a make -j4 after a make clean). > If folks are interested in this I can look at quieting the remaining > output. My intention would be to still output something on entry to a > directory that would take a non-trivial amount of time (like > src/backend). Though if it's very likely that the CMake stuff is going > to happen (is it?) then I don't think it's worth it. TBH, I flat out don't want this. Normally I want "-s" mode, ie *no* routine output, and when I don't want that I generally need to see everything. Intermediate levels of verbosity are just an annoyance. 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
Re: [HACKERS] Shrink volume of default make output
On 1/2/17 3:57 PM, Tom Lane wrote: Jim Nasby writes: The recent thread about compiler warnings got me thinking about how it's essentially impossible to notice warnings with default make output. Perhaps everyone just uses make -s by default, though that's a bit annoying since you get no output unless something does warn (and then you don't know what directory it was in). Is it worth looking into this? I'm guessing this may be moot with the CMake work, but it's not clear when that'll make it in. In the meantime, ISTM http://stackoverflow.com/a/218295 should be an easy change to make (though perhaps with a variable that gives you the old behavior). I'm not really sure which of the kluges in that article you're proposing we adopt, but none of them look better than "make -s" to me. Also, none of them would do anything about make's own verbosity such as "entering/leaving directory" lines. I was specifically thinking of quieting the compiler lines, along the lines of silencing the CC lines. That would still provide the per directory output for some amount of status. (At first I thought of doing the @echo "Compiling $<" hack, but in retrospect there's probably no use in that.) The attached hack doesn't quiet everything, but makes a significant difference, 1588 lines down to 622, with 347 being make -C (each of those was a make -j4 after a make clean). If folks are interested in this I can look at quieting the remaining output. My intention would be to still output something on entry to a directory that would take a non-trivial amount of time (like src/backend). Though if it's very likely that the CMake stuff is going to happen (is it?) then I don't think it's worth it. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) diff --git a/src/Makefile.global.in b/src/Makefile.global.in index d39d6ca867..76ec919476 100644 --- a/src/Makefile.global.in +++ b/src/Makefile.global.in @@ -2,6 +2,9 @@ # src/Makefile.global.in # @configure_input@ +SILENT = @ +DOTSILENT = .SILENT + #-- # All PostgreSQL makefiles include this file and use the variables it sets, # which in turn are put here by the configure script. There is no need for @@ -618,9 +621,10 @@ TAS = @TAS@ # # Global targets and rules + %.c: %.l ifdef FLEX - $(FLEX) $(if $(FLEX_NO_BACKUP),-b) $(FLEXFLAGS) -o'$@' $< + $(SILENT) $(FLEX) $(if $(FLEX_NO_BACKUP),-b) $(FLEXFLAGS) -o'$@' $< @$(if $(FLEX_NO_BACKUP),if [ `wc -l &2; exit 1; fi) else @$(missing) flex $< '$@' @@ -629,19 +633,20 @@ endif %.c: %.y $(if $(BISON_CHECK_CMD),$(BISON_CHECK_CMD)) ifdef BISON - $(BISON) $(BISONFLAGS) -o $@ $< + $(SILENT) $(BISON) $(BISONFLAGS) -o $@ $< else @$(missing) bison $< $@ endif %.i: %.c - $(CPP) $(CPPFLAGS) -o $@ $< + $(SILENT) $(CPP) $(CPPFLAGS) -o $@ $< %.gz: % - $(GZIP) --best -c $< >$@ + $(SILENT) $(GZIP) --best -c $< >$@ %.bz2: % - $(BZIP2) -c $< >$@ + $(SILENT) $(BZIP2) -c $< >$@ + # Direct builds of foo.c -> foo are disabled to avoid generating # *.dSYM junk on Macs. All builds should normally go through the @@ -785,10 +790,11 @@ ifeq ($(GCC), yes) # GCC allows us to create object and dependency file in one invocation. %.o : %.c @if test ! -d $(DEPDIR); then mkdir -p $(DEPDIR); fi - $(COMPILE.c) -o $@ $< -MMD -MP -MF $(DEPDIR)/$(*F).Po + $(SILENT) $(COMPILE.c) -o $@ $< -MMD -MP -MF $(DEPDIR)/$(*F).Po endif # GCC + # Include all the dependency files generated for the current # directory. Note that make would complain if include was called with # no arguments. diff --git a/src/backend/Makefile b/src/backend/Makefile index a1d3f067d7..8a8e439f6f 100644 --- a/src/backend/Makefile +++ b/src/backend/Makefile @@ -53,6 +53,8 @@ endif all: submake-libpgport submake-schemapg postgres $(POSTGRES_IMP) +$(DOTSILENT): postgres + ifneq ($(PORTNAME), cygwin) ifneq ($(PORTNAME), win32) ifneq ($(PORTNAME), aix) diff --git a/src/backend/common.mk b/src/backend/common.mk index 5d599dbd0c..66b5a0c573 100644 --- a/src/backend/common.mk +++ b/src/backend/common.mk @@ -26,9 +26,10 @@ endif SUBSYS.o: $(SUBDIROBJS) $(OBJS) $(LD) $(LDREL) $(LDOUT) $@ $^ + objfiles.txt: Makefile $(SUBDIROBJS) $(OBJS) # Don't rebuild the list if only the OBJS have changed. - $(if $(filter-out $(OBJS),$?),( $(if $(SUBDIROBJS),cat $(SUBDIROBJS); )echo $(addprefix $(subdir)/,$(OBJS)) ) >$@,touch $@) + $(SILENT) $(if $(filter-out $(OBJS),$?),( $(if $(SUBDIROBJS),cat $(SUBDIROBJS); )echo $(addprefix $(subdir)/,$(OBJS)) ) >$@,touch $@) # make function to expand objfiles.txt contents expand_subsys = $(foreach file,$(1),$(if $(filter %/objfiles.txt,$(file)),$(patsubst ../../src/b
Re: [HACKERS] Shrink volume of default make output
Jim Nasby writes: > The recent thread about compiler warnings got me thinking about how it's > essentially impossible to notice warnings with default make output. > Perhaps everyone just uses make -s by default, though that's a bit > annoying since you get no output unless something does warn (and then > you don't know what directory it was in). > Is it worth looking into this? I'm guessing this may be moot with the > CMake work, but it's not clear when that'll make it in. In the meantime, > ISTM http://stackoverflow.com/a/218295 should be an easy change to make > (though perhaps with a variable that gives you the old behavior). I'm not really sure which of the kluges in that article you're proposing we adopt, but none of them look better than "make -s" to me. Also, none of them would do anything about make's own verbosity such as "entering/leaving directory" lines. 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
[HACKERS] Shrink volume of default make output
The recent thread about compiler warnings got me thinking about how it's essentially impossible to notice warnings with default make output. Perhaps everyone just uses make -s by default, though that's a bit annoying since you get no output unless something does warn (and then you don't know what directory it was in). Is it worth looking into this? I'm guessing this may be moot with the CMake work, but it's not clear when that'll make it in. In the meantime, ISTM http://stackoverflow.com/a/218295 should be an easy change to make (though perhaps with a variable that gives you the old behavior). -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
