0

This is a debugging question. I am trying to integrate Qt moc'ing into a CMake managed project using the AUTOMOC feature. I have not managed to generate a project which includes moc rules, though I believe I followed the guidelines.

I've checked with the following command that the expected files are indeed listed :

get_target_property(MY_PROJECT_SOURCES CMAKETEST SOURCES)
message("${MY_PROJECT_SOURCES}")

I did notice that ${AUTOMOC_MACRO_NAMES} was initially empty and not initialized to CMAKE_AUTOMOC_MACRO_NAME as the documentation claims, which may be a hint as to the cause of the problem. I tried to add an explicit set(AUTOMOC_MACRO_NAMES "${CMAKE_AUTOMOC_MACRO_NAMES}") to try to work around that.

I've written a MCVE which reproduces the problem on my system. Here is the CMakeList file :

# CMake version expected
cmake_minimum_required(VERSION 3.18)

# Project title
project(CMAKETEST)

# specify the C++ standard
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED True)

# specify source files
set(DIR_SRC "${CMAKETEST_SOURCE_DIR}/src")
file(GLOB_RECURSE SRC_LIST ${DIR_SRC}/*.cpp ${DIR_SRC}/*.h ${DIR_SRC}/*.hpp)

add_executable(CMAKETEST ${SRC_LIST})


# include Qt

# enable Qt support
set_target_properties(CMAKETEST PROPERTIES AUTOMOC TRUE)
set_target_properties(CMAKETEST PROPERTIES AUTOUIC TRUE)
set_target_properties(CMAKETEST PROPERTIES AUTORCC TRUE)

# Find Qt libs
set(QT_DIR $ENV{QT_HOME_DIR})
set(CMAKE_PREFIX_PATH "${QT_DIR}")
find_package(Qt5 COMPONENTS Core REQUIRED)
target_link_libraries(CMAKETEST Qt5::Core)
set(AUTOMOC_MACRO_NAMES "${CMAKE_AUTOMOC_MACRO_NAMES}")

The project file tree looks like :

project_root
│   CMakeLists.txt
│
├───build
└───src
        main.cpp
        my_qt_obj.cpp
        my_qt_obj.h

my_qt_obj.h :

#pragma once
#include <QObject>

class my_qt_obj : public QObject
{
    Q_OBJECT
public slots:
    void my_slot();
signals:
    void my_sig();
};

my_qt_obj.cpp :

#include "my_qt_obj.h"
void my_qt_obj::my_slot() {}

main.cpp :

#include "my_qt_obj.h"
int main() {
    my_qt_obj foo;
    QObject::connect(&foo, &my_qt_obj::my_sig, &foo, &my_qt_obj::my_slot);
}

Predictably, since no moc rules are generated, I get a linking error due to unresolved external symbols. But there are no errors reported by CMake.

The command I use to build is : cmake -S . -B build -A x64 from the project root directory. I am using CMake 3.18.3 with Qt 5.15.1 compiled from source. The commands used to compile Qt are :

"%QT_SRC%\configure" -prefix "%QT_OUT%" -platform win32-msvc -opengl desktop -make libs -nomake examples -nomake tests -skip qtwebengine -opensource
nmake    
nmake install

My attempts have all been targeting Visual Studio 2017.

vre
  • 6,041
  • 1
  • 25
  • 39
François Andrieux
  • 28,148
  • 6
  • 56
  • 87
  • As far as I can see the properties are named `AUTOMOC, AUTOUIC, AUTORCC` on the target `CMAKETEST` (without the `CMAKE_` prefix). Another possibility to check is to set them globally via `set(CMAKE_AUTOMOC TRUE) ... `, but that influences all targets. – vre Nov 21 '20 at 23:46
  • @vre Thank you for your suggestion. [CMAKE_AUTOMOC](https://cmake.org/cmake/help/latest/variable/CMAKE_AUTOMOC.html) sets the default value, but I've switched to just using `AUTOMOC` instead as it seems more appropriate. I've tried both version with both `set` and `set_target_properties` (four distinct tests) and the results were unfortunately unchanged. I'll edit the question to use `AUTOMOC` instead, for clarity. – François Andrieux Nov 22 '20 at 00:13
  • 1
    I just checked your MCVE example with generator "Visual Studio 16 2019" and build with `cmake --build build --config Release --target ALL_BUILD`. Everything was working as expected. What was the exact error message? – vre Nov 22 '20 at 12:58
  • @vre Well, after trying to run that command manually (`cmake --build build --config Release --target ALL_BUILD`) everything works fine. In fact, I cannot reproduce the original problem anymore... I've tried starting over from scratch and the problem seems to have disappeared. I am not even able to create a new MCVE that produces this problem. This was my first attempt at using CMake, so maybe my configuration was broken in some way, which the successful build fixed. Although everything works well now, I have to admit I am very confused. – François Andrieux Nov 22 '20 at 14:47
  • 1
    @vre Thank you for your time and effort. – François Andrieux Nov 22 '20 at 14:48

0 Answers0