Marcus D. Hanwell wrote: > On Wed, Feb 6, 2013 at 5:46 AM, Stephen Kelly > <[email protected]> wrote: >> >> Hi there, >> >> The qt4_use_modules is now mostly obsoleted by tll in CMake 2.8.11. The >> main difference is that qt4_use_modules does not require the use of >> imported targets. >> >> I think we should deprecate it in favor of using tll() with imported >> targets (using the imported targets is independent of the >> QT_USE_IMPORTED_TARGETS setting, which determines what is in the >> QT_QTGUI_LIBRARIES and similar variables). So we should document >> >> target_link_libraries(foo PRIVATE Qt4::QtGui) >> >> and similar as the primary way to use Qt 4. >> >> The qt4_automoc macro is obsoleted by the CMAKE_AUTOMOC feature. There is >> no equivalent in the Qt 5 cmake macro offering. So, I think we should >> deprecate it too. >> > What do you mean by deprecate it?
Good question. I thought about it too, but forgot to write about it in my mail. One example of a deprecated macro is WRITE_BASIC_CONFIG_VERSION_FILE, which is documented as deprecated (no runtime usage warning or anything). So, we could simply document the macros as deprecated, not recommended for new code, and not available when using Qt 5. 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 have projects that don't require > a recent CMake, and I would rather not add two ways of doing things to > the CMake code. 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. > I will certainly use this in newer projects that > require a recent CMake. It would be irritating to see deprecation > notices popping up in our dashboards too, so I would rather see them > continue to be supported. > > As there will be no more Qt 4 releases, wouldn't there be a natural > deprecation path as projects move over to Qt 5? Yes. I think it is no harm to document them as deprecated and not recommended for use in new projects anyway. 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
