Thread: make --silent
I have noticed that some people post examples using make --silent (-s). I found this actually kind of neat to use from time to time, because then you only see output if you have warnings or errors. But we get some extra output that doesn't quite fit: Writing postgres.bki Writing schemapg.h Writing postgres.description Writing postgres.shdescription Writing fmgroids.h Writing fmgrtab.c Processing HTML.index... 2406 entries loaded... 0 entries ignored... Done. Note: Writing man3/SPI_connect.3 Note: Writing man3/SPI_finish.3 Note: Writing man3/SPI_push.3 ... Note: Writing man1/pg_test_timing.1 Note: Writing man1/pg_upgrade.1 Note: Writing man1/pg_xlogdump.1 In file included from gram.y:13612:0: scan.c: In function ‘yy_try_NUL_trans’: scan.c:10181:23: warning: unused variable ‘yyg’ [-Wunused-variable] PostgreSQL, contrib, and documentation successfully made. Ready to install. Is there interest in silencing this extra output (not the compiler warning) when make -s is used? The documentation tools have options to do so, the rest are our own scripts.
On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote: > I have noticed that some people post examples using make --silent (-s). > I found this actually kind of neat to use from time to time, because > then you only see output if you have warnings or errors. But we get > some extra output that doesn't quite fit: I am one of the people doing that regularly. I think it's fantastic because it's so much harder to miss errors that way... Also it shortens the buildtime measurably. > Writing postgres.bki > Writing schemapg.h > Writing postgres.description > Writing postgres.shdescription > Writing fmgroids.h > Writing fmgrtab.c I personally don't feel the need for those to go away. They only appear when doing a clean rebuild and/or when changing something significant. Also it's just a couple of lines. > Processing HTML.index... > 2406 entries loaded... > 0 entries ignored... > Done. > Note: Writing man3/SPI_connect.3 > Note: Writing man3/SPI_finish.3 > Note: Writing man3/SPI_push.3 > ... > Note: Writing man1/pg_test_timing.1 > Note: Writing man1/pg_upgrade.1 > Note: Writing man1/pg_xlogdump.1 Those should imo be silenced. It's quite a bit of output, and especially during a parallel build they tend to hide more important output. > In file included from gram.y:13612:0: > scan.c: In function ‘yy_try_NUL_trans’: > scan.c:10181:23: warning: unused variable ‘yyg’ [-Wunused-variable] > PostgreSQL, contrib, and documentation successfully made. Ready to install. FWIW, I've patched debian's flex just to get rid of this ;) Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
* Andres Freund (andres@2ndquadrant.com) wrote:
> On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote:
> > Writing postgres.bki
> > Writing schemapg.h
> > Writing postgres.description
> > Writing postgres.shdescription
> > Writing fmgroids.h
> > Writing fmgrtab.c
>
> I personally don't feel the need for those to go away. They only appear
> when doing a clean rebuild and/or when changing something
> significant. Also it's just a couple of lines.
For my 2c, I'd be for getting rid of the above. I agree it's not a huge
deal, but I'm also a big fan of "don't spam me when things go right".
Is there any particular reason we need to see them with every (clean)
build..?
> > Processing HTML.index...
> > 2406 entries loaded...
> > 0 entries ignored...
> > Done.
> > Note: Writing man3/SPI_connect.3
> > Note: Writing man3/SPI_finish.3
> > Note: Writing man3/SPI_push.3
> > ...
> > Note: Writing man1/pg_test_timing.1
> > Note: Writing man1/pg_upgrade.1
> > Note: Writing man1/pg_xlogdump.1
>
> Those should imo be silenced. It's quite a bit of output, and especially
> during a parallel build they tend to hide more important output.
Agreed.
> > In file included from gram.y:13612:0:
> > scan.c: In function ‘yy_try_NUL_trans’:
> > scan.c:10181:23: warning: unused variable ‘yyg’ [-Wunused-variable]
> > PostgreSQL, contrib, and documentation successfully made. Ready to install.
>
> FWIW, I've patched debian's flex just to get rid of this ;)
Any idea if that might be accepted upstream or perhaps by Debian..? It
would surely be nice to make that error go away..
Thanks,
Stephen
Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote:
>> I have noticed that some people post examples using make --silent (-s).
>> I found this actually kind of neat to use from time to time, because
>> then you only see output if you have warnings or errors. But we get
>> some extra output that doesn't quite fit:
>> Writing postgres.bki
>> Writing schemapg.h
>> Writing postgres.description
>> Writing postgres.shdescription
>> Writing fmgroids.h
>> Writing fmgrtab.c
> I personally don't feel the need for those to go away.
I agree --- these let you know that something happened that does not
happen every build, so they're kind of useful. I concur that the noise
from doc building is just noise, though.
>> In file included from gram.y:13612:0:
>> scan.c: In function ‘yy_try_NUL_trans’:
>> scan.c:10181:23: warning: unused variable ‘yyg’ [-Wunused-variable]
>> PostgreSQL, contrib, and documentation successfully made. Ready to install.
> FWIW, I've patched debian's flex just to get rid of this ;)
I think it's fixed officially as of flex 2.5.35.
regards, tom lane
On 2013-07-23 09:21:54 -0400, Stephen Frost wrote: > * Andres Freund (andres@2ndquadrant.com) wrote: > > On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote: > > > Writing postgres.bki > > > Writing schemapg.h > > > Writing postgres.description > > > Writing postgres.shdescription > > > Writing fmgroids.h > > > Writing fmgrtab.c > > > > I personally don't feel the need for those to go away. They only appear > > when doing a clean rebuild and/or when changing something > > significant. Also it's just a couple of lines. > > For my 2c, I'd be for getting rid of the above. I agree it's not a huge > deal, but I'm also a big fan of "don't spam me when things go right". > Is there any particular reason we need to see them with every (clean) > build..? I don't have a big problem with getting rid of them either. I find them moderately reassuring to see those triggered if I change something relevant because I don't fully trust the dependency mechanism around them, but that's about it. > > > In file included from gram.y:13612:0: > > > scan.c: In function ‘yy_try_NUL_trans’: > > > scan.c:10181:23: warning: unused variable ‘yyg’ [-Wunused-variable] > > > PostgreSQL, contrib, and documentation successfully made. Ready to install. > > > > FWIW, I've patched debian's flex just to get rid of this ;) > > Any idea if that might be accepted upstream or perhaps by Debian..? It > would surely be nice to make that error go away.. I think Tom ushered a patch upstream, debian just hasn't updated in a good while, even in unstable. I've looked at the packages bug page some time back and it didn't look very active so I didn't think further about proposing a debian-only backport of that patch. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 2013-07-23 09:27:18 -0400, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote: > >> In file included from gram.y:13612:0: > >> scan.c: In function ‘yy_try_NUL_trans’: > >> scan.c:10181:23: warning: unused variable ‘yyg’ [-Wunused-variable] > >> PostgreSQL, contrib, and documentation successfully made. Ready to install. > > > FWIW, I've patched debian's flex just to get rid of this ;) > > I think it's fixed officially as of flex 2.5.35. Unfortunately (because debian has 2.5.35) it seems to be 2.5.36. The former was released 2008 :( It's 62617a3183abb2945beedc0b0ff106182af4f266 in flex's repository if somebody wants to submit it to debian. The repository is at git://git.code.sf.net/p/flex/flex - their website stated a different url the last time I looked. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services