Re: [libmicrohttpd] Add 'manywarnings' module from Wget2

[Tim Rühsen]

On Montag, 19. Juni 2017 18:48:47 CEST Evgeny Grin wrote:
> On 18.06.2017 13:45, Tim Rühsen wrote:
> > maybe you like this...
> > 
> > "    Add m4/wget_manywarnings
> > 
> >     This enables (if switched on) basically all warnings for gcc and
> >     clang.
> >     Exceptions are explicitly controlled in configure.ac.
> >     
> >     To enable by default: create a file '.manywarnings'
> >     Enable explicitly : ./configure --enable-manywarnings
> >     Disable explicitly: ./configure --disable-manywarnings
> >     
> >     New warnings of new compiler versions are automatically added.
> >     This module works much faster than the 'manywarnings' module from
> >     gnulib.
> >     
> >     Created for developers and Continuous Integration."
> > 
> > I just added the WARN_FLAGS to src/microhttpd/Makefile.am, but if you like
> > it add it also to the other Makefile.am.
> > 
> > It might need some further tuning in configure.ac to enable/disable
> > warnings (I just copied the code from Wget2 were we ignore certain
> > warning).
> 
> Hi Tim,
> 

Hi Evgeny,

> While idea is generally looks good, proposed implementation do not suit
> well from my point of view.
> 
> Code is not self-explainable, so it should be well-documented.

Good point. I would add some explanations to wget_manywarnings.m4 and to 
configure.ac then. If you have detailed proposals, let me know.

> For compatibility with future versions, code should test compiler
> acceptance for added flags. Otherwise software may fail to build with
> some new GCC/clang version.

Checking all compiler flags is a long process. The 'manywarnings.m4' from 
gnulib already does this and it is awfully slow.

This new approach uses for gcc:
gcc -Q --help=c

So all the compiler flags work fine, the problem with new / old compiler 
versions is automatically being circumvented.

Same with clang (using -Weverything) - unlikely that this option will be 
revoked soon.

Not to forget: this is a developer only tool, who are interested in best code 
quality. Typical contributors don't use it, but it's nice for maintainers as a 
test before committing patches.

> Test for "gcc" is not correct:
> ------------
>     case $CC in
>       *gcc*) CCNAME="gcc";;
>       *clang*) CCNAME="clang";;
>     esac
> ------------
> 
> This fail on Darwin (where 'gcc' is symlink for 'clang') and on any
> other platform with such symlink.
> Moreover, 'gcc' could match directory part. For example
> CC='/opt/compilers/gcc-like/clang-4.0/bin/clang' will be detected as 'gcc'.

Thanks for pointing this out. My first approach was using '$CC --version', but 
the output even for gcc is so different on different platforms that I gave up.

So the detection is a 'works for all of us developers so far'. But none of us 
develops on Darwin. We use a recent Linux plus recent developer tools.
On our CI runners we don't switch this option on (e.g. not for MinGW builds 
ans Wine testing).

What do you suggest ? Should we use 'basename' to strip the path before the 
test ?

Regards, Tim

signature.asc
Description: This is a digitally signed message part.