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
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Reply via email to