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.
