Do get less lines when using a less verbose make: diff --git a/configure.ac b/configure.ac index 09b81e6..d7bba63 100644 --- a/configure.ac +++ b/configure.ac @@ -57,6 +57,8 @@ AC_CANONICAL_HOST AC_DEFINE_UNQUOTED([OS_TYPE], "$host_os", [Define to be the name of the operating system.]) +dnl Non-verbose make +m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])]) dnl dnl Process External Libraries
Tim Am Freitag, 29. Januar 2016, 15:52:45 schrieb Darshit Shah: > For example, variable length arrays and the "inline" keyword are both > flagged by the compiler as an extension and gnulib and gettext bit use > them heavily. Without this patch, my builds on travis are failing > because the output logs are > 4MB. > > At the risk of starting another fight, can we move to C99 as the > standard? The only major compiler I know of that doesn't support it is > MSVC. But do we really need to stay so much behind times to support > MSVC? Windows users can use CygWin / MingW to compile Wget. Half of > gnulib, gettext or other libraries will probably not compile properly > using MSVC anyways. Microsoft is not keen on improving their support > for C runtimes. > > Is there anything else that I'm missing? > > On 29 January 2016 at 15:45, Darshit Shah <dar...@gmail.com> wrote: > > Most of them are actually false positives, probably due to us. Gnulib > > uses some more modern code extensions and the compiler keeps warning > > us about it since we set the C language to std=gnu89. I'm not happy > > about this fact, but this discussion has happened multiple times and I > > don't think we will be moving to a more modern setup anytime soon. I > > would personally prefer using *at least* C99, a more recent version > > like C11 would be even better, but not all compiler would support > > that. > > > > On 29 January 2016 at 15:40, Eli Zaretskii <e...@gnu.org> wrote: > >>> From: Darshit Shah <dar...@gmail.com> > >>> Date: Fri, 29 Jan 2016 15:18:57 +0100 > >>> > >>> A recent GCC / LLVM update has caused my setup to spew far too many > >>> warnings on compiling Wget. On a closer look, they all come from > >>> Gnulib code. I propose the attached patch to explicitly mark those > >>> files as libraries and have the compiler suppress warnings from them. > >>> This way we can focus on the warnings generated by Wget codebase > >>> alone. > >> > >> If we do this, who will tell Gnulib people to get their act together > >> and fix those warnings? I think the right solution to this is in > >> Gnulib, not in Wget. > >> > >> Thanks. > > > > -- > > Thanking You, > > Darshit Shah
signature.asc
Description: This is a digitally signed message part.