CMAKE_AUTO{MOC,RCC,UIC}_EXECUTABLE behavior in older versions of cmake

Code
1

For some reasons I cannot use find_package to configure Qt5 in my project.

In last versions of cmake I just could write something like that

set(CMAKE_AUTOMOC_EXECUTABLE "${QT_BIN_DIR}/moc")
set(CMAKE_AUTOUIC_EXECUTABLE "${QT_BIN_DIR}/uic")
set(CMAKE_AUTORCC_EXECUTABLE "${QT_BIN_DIR}/rcc")
add_executable(name ...)
add_library(name ...)

and it would work perfectly.

But in cmake versions less than 3.27 (particularly 3.14) it does not work at all.

So question is how could I imitate CMAKE_AUTO*_EXECUTABLE behavior? Which properties should I manually set to make it work automatically for all subsequent targets?

2

Found the answer by myself. For those who also is interested:

It is required to set QT_VERSION_{MAJOR,MINOR,PATCH} variables and Qt5::{qmake,moc,rcc,uic} targets:

add_executable(Qt5::qmake IMPORTED)
set_property(TARGET Qt5::qmake PROPERTY IMPORTED_LOCATION ${QT_QMAKE_EXECUTABLE})

...
3

Never needed to set any of those, the following was usually enough (assuming that path to Qt is passed in CMAKE_PREFIX_PATH):

# annoyingly enough, it has to be all capital `QT` in the first `find_package()`
find_package(QT NAMES Qt5 REQUIRED COMPONENTS Widgets)
find_package(Qt5 COMPONENTS Widgets REQUIRED)

set(CMAKE_AUTOUIC ON)
set(CMAKE_AUTOMOC ON)
#set(CMAKE_AUTORCC ON) # if you are not using `qt_add_resources()`

target_link_libraries(${CMAKE_PROJECT_NAME}
    PRIVATE
        Qt5::Widgets
)

And if you really need to set the CMAKE_AUTOMOC_EXECUTABLE and others, then the following should do:

set(CMAKE_AUTOMOC_EXECUTABLE "${QT_HOME}/bin/moc")

Though I’ve never used CMake as old as 3.14, so maybe there is something different there?

…Ha, documentation does say that AUTO{MOC,UIC,RCC}_EXECUTABLE were added exactly in version 3.14, but the actual(?) reason for your problem seems to be the 3.27 version - just as you mentioned - because CMAKE_AUTO{MOC,UIC,RCC}_EXECUTABLE (note the CMAKE_ prefix) first appeared in that one (which means that setting them with older CMake versions won’t affect the AUTO{MOC,UIC,RCC}_EXECUTABLE properties).

4

As I said I am unable to use find_package for Qt5.

The reason is that the Qt is cross-compiled and has invalid cmake-configuration which refers to wrong directories but still has a correct qt.conf. So I had to write my own FindQt module, which configures Qt relying on qmake -query calls. Like original FindQt{3,4} did.

And I don’t know why the community decided to give up with FindQt modules. Their usage looked more suitable because only qmake knows which paths are right.

5

The reason is that the Qt is cross-compiled and has invalid cmake-configuration which refers to wrong directories

That you did not mention in your original post, and it makes your reasoning for not using find_package() a bit more clear, although still not entirely clear, but since it is Qt 5.x, which isn’t yet handled with CMake, that probably makes it more likely to get a “broken” package with incorrect paths, as you say. Though I would still blame the package maker.

why the community decided to give up with FindQt modules

I reckon that is due to the switch from qmake to CMake, since Qt 6.x now produces proper(?) CMake packages with configs.