# CMAKE\_AUTO{MOC,RCC,UIC}\_EXECUTABLE behavior in older versions of cmake

**URL:** <https://discourse.cmake.org/t/cmake-auto-moc-rcc-uic-executable-behavior-in-older-versions-of-cmake/15239>\
**Category:** Code\
**Tags:** os:linux\
**Created:** [October 14, 2025, 12:06pm UTC](https://discourse.cmake.org/t/cmake-auto-moc-rcc-uic-executable-behavior-in-older-versions-of-cmake/15239 "2025-10-14T12:06:36Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![sergeniously](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/s/e495f1/32.png) [@sergeniously](https://discourse.cmake.org/u/sergeniously)\
**Post date:** [October 14, 2025, 12:06pm UTC](https://discourse.cmake.org/t/cmake-auto-moc-rcc-uic-executable-behavior-in-older-versions-of-cmake/15239/1 "2025-10-14T12:06:37Z")

</div>

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

```cmake
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?

---

<div class="post-metadata">

**Author:** ![sergeniously](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/s/e495f1/32.png) [@sergeniously](https://discourse.cmake.org/u/sergeniously)\
**Post date:** [October 14, 2025, 6:04pm UTC](https://discourse.cmake.org/t/cmake-auto-moc-rcc-uic-executable-behavior-in-older-versions-of-cmake/15239/2 "2025-10-14T18:04:52Z")

</div>

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:

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

...

```

---

<div class="post-metadata">

**Author:** ![retif](https://discourse.cmake.org/user_avatar/discourse.cmake.org/retif/32/1776_2.png) [@retif](https://discourse.cmake.org/u/retif)\
**Post date:** [October 14, 2025, 6:41pm UTC](https://discourse.cmake.org/t/cmake-auto-moc-rcc-uic-executable-behavior-in-older-versions-of-cmake/15239/3 "2025-10-14T18:41:52Z")

</div>

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

```cmake
# 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:

```cmake
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](https://cmake.org/cmake/help/latest/prop_tgt/AUTOMOC_EXECUTABLE.html), but the actual(?) reason for your problem seems to be the [3.27](https://cmake.org/cmake/help/latest/variable/CMAKE_AUTOMOC_EXECUTABLE.html) 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_).

---

<div class="post-metadata">

**Author:** ![sergeniously](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/s/e495f1/32.png) [@sergeniously](https://discourse.cmake.org/u/sergeniously)\
**Post date:** [October 15, 2025, 7:58am UTC](https://discourse.cmake.org/t/cmake-auto-moc-rcc-uic-executable-behavior-in-older-versions-of-cmake/15239/4 "2025-10-15T07:58:21Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![retif](https://discourse.cmake.org/user_avatar/discourse.cmake.org/retif/32/1776_2.png) [@retif](https://discourse.cmake.org/u/retif)\
**Post date:** [October 15, 2025, 8:43am UTC](https://discourse.cmake.org/t/cmake-auto-moc-rcc-uic-executable-behavior-in-older-versions-of-cmake/15239/5 "2025-10-15T08:43:01Z")

</div>

> 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.