Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] CMake status

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Tue, 6 Jan 2015 19:15:17 -0800
On Jan 6, 2015, at 3:26 AM, Graham Bloice <graham.bloice@xxxxxxxxxxxxx> wrote:

> >       • Fix compile warnings.
> 
> Are there compile warnings we're getting from the CMake build that we're not getting from the nmake build?
> 
> Yes, See the end of the last successful buildbot Cmake build (it appears to be broken again) http://buildbot.wireshark.org/trunk/builders/Windows%207%20x64/builds/11848/steps/shell_2/logs/stdio
> 
> One warning about dup messages in the Italian translation and two warnings about dup definitions when compiling packet-kerberos.  These may be artefacts of the CMake build rather than actual warnings to be fixed in code.

The warnings about duplicate definitions are the result of the CMake build checking for the presence of <stdlib.h> and <string.h>.  Our source doesn't, and shouldn't, check HAVE_STRING_H or HAVE_STDLIB_H, as we don't, and shouldn't, try to work on environments that aren't at least a hosted C89 environment.

autoconf checks for them because it dates back to the pre-ANSI C days, when it might have been useful to check for them.  Apparently

	Most generic macros use the following macro to provide the default set of includes:

	— Macro: AC_INCLUDES_DEFAULT ([include-directives])

to quote the autoconf manual, and that macro checks for those headers, so our autoconf file is probably checking for it because some other macro we're using uses AC_INCLUDES_DEFAULT.

nmake doesn't bother setting HAVE_STRING_H or HAVE_STDLIB_H, which is why it doesn't show up with nmake.

We could:

	1) remove the checks for those headers - this would only cause issues if there are headers that we include that require those headers on platforms where they're present and protect the includes with those #defines;

	2) do the tests only on UN*X, not on Windows;

	3) try to arrange to define it the same way KfW's win-mac.h defines it.

My personal inclination is to do 1), as that's cleaner, and exported header files should never ever ever ever ever ever ever ever ever ever ever ever ever ever check autoconf #defines in #ifdefs (that makes programs using your package have to define them appropriately, but they shouldn't have to know about that).