[cmake-developers] Deprecating qt4_use_modules and qt4_automoc?
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. Thoughts? 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
Re: [cmake-developers] Deprecating qt4_use_modules and qt4_automoc?
On Wed, Feb 6, 2013 at 5:46 AM, Stephen Kelly steve...@gmail.com 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? 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. 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? Marcus -- 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
Re: [cmake-developers] Deprecating qt4_use_modules and qt4_automoc?
-Original Message- From: Marcus D. Hanwell marcus.hanw...@kitware.com To: Stephen Kelly steve...@gmail.com Cc: cmake-developers cmake-developers@cmake.org Sent: Wed, Feb 6, 2013 7:55 am Subject: Re: [cmake-developers] Deprecating qt4_use_modules and qt4_automoc? On Wed, Feb 6, 2013 at 5:46 AM, Stephen Kelly steve...@gmail.com 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? 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. 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? Marcus -- 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 I agree with Marcus. There's no reason to deprecate these (other than deprecating Qt4 entirely, but not yet) unless there's a significant code clarity advantage. What does it buy us to deprecate these things now? If you're just trying to point people to the new stuff, just point them to Qt5 examples. D -- 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
Re: [cmake-developers] Deprecating qt4_use_modules and qt4_automoc?
David Cole wrote: I agree with Marcus. There's no reason to deprecate these (other than deprecating Qt4 entirely, but not yet) unless there's a significant code clarity advantage. I think in the case of the qt4_automoc macro at least, there's some technical issue with changes in dependencies. Alex knows more. What does it buy us to deprecate these things now? Good advice in documentation I guess, if there's technical reasons not to use them. From a porting point of view (in terms of porting to newer cmake or newer Qt), it might be easier if they are not used (provided a new enough cmake version is used). It's never too early to have one eye on porting, and if the documentation tells you that using a macro makes porting harder, you can take note :). Also, if starting a new project, it makes sense to not use stuff (from the beginning) that will not be available/is not recommended/has disadvantages. For that though, there needs to be some indication of what is deprecated. 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
Re: [cmake-developers] Deprecating qt4_use_modules and qt4_automoc?
-Original Message- From: Stephen Kelly steve...@gmail.com To: cmake-developers cmake-developers@cmake.org Sent: Wed, Feb 6, 2013 8:17 am Subject: Re: [cmake-developers] Deprecating qt4_use_modules and qt4_automoc? David Cole wrote: I agree with Marcus. There's no reason to deprecate these (other than deprecating Qt4 entirely, but not yet) unless there's a significant code clarity advantage. I think in the case of the qt4_automoc macro at least, there's some technical issue with changes in dependencies. Alex knows more. What does it buy us to deprecate these things now? Good advice in documentation I guess, if there's technical reasons not to use them. From a porting point of view (in terms of porting to newer cmake or newer Qt), it might be easier if they are not used (provided a new enough cmake version is used). It's never too early to have one eye on porting, and if the documentation tells you that using a macro makes porting harder, you can take note :). Also, if starting a new project, it makes sense to not use stuff (from the beginning) that will not be available/is not recommended/has disadvantages. For that though, there needs to be some indication of what is deprecated. 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 OK, sure. If something's not recommended moving forward, by all means document it that way. Deprecation to me means more of an active warning against using something at runtime, or producing an error if something is used that is not recommended. But if you are advising just updating docs, then go for it. D -- 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
[cmake-developers] Depends information in buildsystem files
Hi there, I've pushed a branch with some addtional fixes for various issues in generator expressions. One of the issues relates to depends information in the build dir. I fixed the situation in the makefile generator by expanding the COMPILE_DEFINITIONS before writing out the DependsInfo.cmake file. The Ninja generator doesn't use such a file, but from my porcelain test it seems to already detect the INTERFACE content appropriately. I didn't check how that works. It occurs to me though that this could be not just one bug but a class of bugs. A similar issue could exist for the other generators, and anywhere else that cmake generates 'buildsystem artifacts' which make need to be evaluated as generator expressions, or may need to take INTERFACE content of dependencies into account. I wouldn't know what to look for in other generators. Any idea if a similar issue could occur elsewhere? Another possible candidate is target_LIB_DEPENDS in the cache. Currently, cmTarget::AddLinkLibrary aborts if a generator expression is found before populating that cache variable. Is that appropriate? 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
