[cmake-developers] Deprecating qt4_use_modules and qt4_automoc?

[Stephen Kelly]

Marcus D. Hanwell wrote:

> On Wed, Feb 6, 2013 at 5:46 AM, Stephen Kelly
> <steveire at 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? 

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.