[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 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 To: Stephen Kelly Cc: cmake-developers 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 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?
Marcus D. Hanwell wrote: > On Wed, Feb 6, 2013 at 5:46 AM, Stephen Kelly > 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
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 To: cmake-developers 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
Re: [cmake-developers] Deprecating qt4_use_modules and qt4_automoc?
On Wed, Feb 6, 2013 at 8:21 AM, David Cole wrote: > -Original Message- > From: Stephen Kelly > To: cmake-developers > 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. > > > 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. I entirely echo Dave's words here - I thought you meant more of an active warning against using it at runtime/producing errors. If all you mean is updating the documentation I think that is a great idea, and it certainly seems like the right way to go here. 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?
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
Re: [cmake-developers] Deprecating qt4_use_modules and qt4_automoc?
Stephen Kelly writes: > 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. > > Comments? Bump! http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6002/focus=6004 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 - > Stephen Kelly writes: > > 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. > > > > Comments? > > Bump! > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6002/focus=6004 > What is the motivation for deprecating these? Can we just let them fade away on their own as the world moves from Qt4 to Qt5? Clint -- 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?
clin...@elemtech.com wrote: > What is the motivation for deprecating these? > Can we just let them fade away on their own as the world moves from Qt4 to > Qt5? This is entirely orthogonal to Qt 5. qt4_use_modules is new, but provides no benefit over tll(). We shouldn't encourage adoption of it for people who are already depending on 2.8.11. qt4_automoc is suboptimal, not present in the Qt 5 macros, and made obsolete by the CMAKE_AUTOMOC feature. With two similar features, one of them should be marked obsolete. 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
