Marcus D. Hanwell wrote:
>> But if you are advising just updating docs, then go for it.
>
> I entirely echo Dave's words here - I thought you meant more of an
> active warning against using it at runtime/producing errors.
Well, actually I did mean runtime warnings. The documentation changes
obviously should be made anyway. There's no point in adding runtime warnings
without updating documentation to say what should be used instead too.
The documentation changes are a minimum to mark macros and functions as
'deprecated' or 'avoid for new projects', but I raised this issue to talk
about going further than that.
So, the question is whether we can come up with an appropriate way to add a
runtime warning. Here again is what I wrote before elsewhere in this thread
which did not get any response:
We could also probably add a runtime warning if enabled. You need to enable
deprecation warnings with your compiler, so it would make sense to have to
enable them with a cmake script too. CMAKE_ENABLE_DEPRECATION_WARNINGS
could be used to determine whether to print a warning in the implementation
of a macro or function.
We could also conditionally enable the deprecation warning depending on the
VERSION used in cmake_minimum_required. Currently I don't think that
version is available to cmake scripts, but that's fixable.
That way:
cmake_minimum_required(VERSION 2.8.3)
set(CMAKE_ENABLE_DEPRECATION_WARNINGS ON)
qt4_automoc(...) # No warning, the minimum version is too old.
# Only warn if the minimum version is 2.8.7.
Comments?
Thanks,
Steve.
--
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
