[cmake-developers] Enabling more compiler warnings
Alexander Neundorf
neundorf at kde.org
Tue Nov 6 11:59:44 EST 2012
On Tuesday 06 November 2012, Stephen Kelly wrote:
> Hi there,
>
> One common reason topcis warn on the dashboard and need to be updated and
> then rebased is that some machines have more warnings enabled by others.
>
> If CMake enabled more warnings by default, developers would notice them
> locally too before even submitting to the dashboard. For example, many of
> my follow up commits have been related to unused parameters, or order of
> initialization in constructors.
>
> I have a branch for enabling some warnings, but it would need to be
> upstream to be of any use:
>
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index ea1c033..3eb1a43 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -586,6 +586,19 @@ option(CMAKE_STRICT
> mark_as_advanced(CMAKE_STRICT)
>
>
> +if("${CMAKE_C_COMPILER_ID}" MATCHES "GNU")
> +
> + set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wcast-align -Werror-implicit-
> function-declaration -Wchar-subscripts -Wall -W")
> + set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wpointer-arith -Wwrite-strings -
> Wformat-security -Wmissing-format-attribute -fno-common")
> + set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wnon-virtual-dtor -ansi -Wcast-
> align -Wchar-subscripts -Wall -W -Wshadow")
> + set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wpointer-arith -Wformat-
> security")
> +
> + if (NOT APPLE)
> + set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--fatal-warnings -Wl,--no-undefined
> ${CMAKE_SHARED_LINKER_FLAGS}")
> + set(CMAKE_MODULE_LINKER_FLAGS "-Wl,--fatal-warnings -Wl,--no-undefined
> ${CMAKE_MODULE_LINKER_FLAGS}")
> + endif ()
> +endif()
> +
>
> I would prefer to also add -Wundef, but kwsys is not clean with that flag
> and creates many warnings, so it would have to be fixed there first.
>
> I'm fairly sure it would work with GCC 4.2 or later (and I guess clang as
> well), which would probably cover many cmake developers. The GCC version
> check only becomes a lot easier with a recent version of CMake (I don't
> recall which), but I'm sure most people do cmake development using the
> development branch anyway, but we'd have to wrap it in a CMAKE_VERSION
> check anyway.
>
> I'd prefer to just do it like this rather than with feature tests, because
> my experience with feature tests on the CMake dashboard (with the export
> header stuff a while back) indicates that it's not worth it in this case.
> It would take far too long to get right.
>
> Any thoughts?
+1
Alex
More information about the cmake-developers
mailing list