uic + CMake + GCC + custom widgets + out-of-source problem

stan423321

Hello. I have a problem with a CMake out-of-source build not setting up the uic-generated header so that it can reach my in-source header with a custom widget. Interestingly, MSVC manages to find it. Do you have any hints? I guess I could throw the source directory into the include path, but that doesn't seem clean.

Here's a minimized example. It does nothing, but it compiles under MSVC 19.25.28614 while not compiling under GCC 10.1.0 (both with out-of-source CMake 3.16/3.17 builds), and I think it illustrates the problem. Of course, in the program I was working on the BetterButton equivalents actually do something, the UI is utilized, etc..

I tried to search for existing information of the internet, but I didn't manage to come up with a combination of keywords that would get anywhere close.

betterbutton.h:

#ifndef HEADER_H
#define HEADER_H
#include <QPushButton>
using BetterButton = QPushButton;
#endif //HEADER_H

CMakeLists.txt:

cmake_minimum_required(VERSION 3.14)
project(minitest)

find_package(Qt5 COMPONENTS Widgets Gui REQUIRED)

add_executable(minitest
    "main.cpp"
    "betterbutton.h"
    "ui.ui"
)

set_target_properties(minitest PROPERTIES AUTOUIC ON AUTOMOC ON AUTORCC ON)

target_link_libraries(minitest PRIVATE Qt5::Core Qt5::Widgets Qt5::Gui)

main.cpp:

#include "ui_ui.h"

int main() {
        return 0;
}

ui.ui:

<?xml version="1.0" encoding="UTF-8"?>
<ui version="4.0">
 <class>Form</class>
 <widget class="QWidget" name="Form">
  <property name="geometry">
   <rect>
    <x>0</x>
    <y>0</y>
    <width>176</width>
    <height>65</height>
   </rect>
  </property>
  <property name="windowTitle">
   <string>Form</string>
  </property>
  <widget class="BetterButton" name="pushButton">
   <property name="geometry">
    <rect>
     <x>20</x>
     <y>20</y>
     <width>75</width>
     <height>23</height>
    </rect>
   </property>
   <property name="text">
    <string>PushButton</string>
   </property>
  </widget>
 </widget>
 <customwidgets>
  <customwidget>
   <class>BetterButton</class>
   <extends>QPushButton</extends>
   <header>betterbutton.h</header>
  </customwidget>
 </customwidgets>
 <resources/>
 <connections/>
</ui>

SGaist

Hi and welcome to devnet,

From the looks of it your forgot to enable CMAKE_AUTOUIC.

See here.

stan423321

@SGaist Thank you for your assistance.
Firstly, adding the three lines setting those global variables does not eliminate the error in question.
Secondly, do they change anything given the following line was already present?

set_target_properties(minitest PROPERTIES AUTOUIC ON AUTOMOC ON AUTORCC ON)

stan423321

I've just realized that the error message would probably be helpful.

In file included from (scrubbed)/min-s/main.cpp:1:
(scrubbed)/min-m/minitest_autogen/include/ui_ui.h:15:10: fatal error: betterbutton.h: No such file or directory
   15 | #include "betterbutton.h"
      |          ^~~~~~~~~~~~~~~~
compilation terminated.

jsulm

@stan423321 said in uic + CMake + GCC + custom widgets + out-of-source problem:

betterbutton.h

Where is it located?

stan423321

All 4 files described in opening post are in the min-s directory. Next to it there's a min-m directory where I build it.

SGaist

You don't seem to add the directory to the include search paths.

stan423321

Is that the standard practice for working with .ui files? It doesn't seem right to me, this breaks the separation of system headers and project ones. Also, I can't help but wonder why MSVC wouldn't need this...

SGaist

I am not sure to follow your question here.

You told us that you have files in subdirectories but yet you do not provide the necessary include paths for the compiler to find the headers in your sub folder.

stan423321

Well, if I include them from .cpp files, both GCC and MSVC automatically know to look in the folder with the source file. I have never before used the include path for in-project files, all the advice I have followed before recommended using include paths just for libraries (e.g. Qt). Not to mention, in a more complex setup, it would break relative paths.

SGaist

It depends all on how you write your includes in your code.

cmake provides the CMAKE_INCLUDE_CURRENT_DIR variable so you can ensure that your project folder is used for the includes.

stan423321

Well, huh. I thought I tried that one with the bigger project before, but it does work with the test program here, so that must have been something else. Thank you for your assistance.