0

I'm porting some of my Qt projects into CMake to make them more flexible across different IDE's.
The only sad part with CMake, when I generate VS solution, it won't work amazingly as it works with the Qt VS Extension.
For example if I change a .ui file, I'll need to rebuild the project in order to see the changes in the GUI in comparison to when I use the VS Extension generated project, it will identify the changes automatically and re-moc the class that owns the .ui file without having to re-build the whole project.
If I look at the project configuration the VS Extension generates in the .vcxproj file, it would add ItemDefinitionGroup some items as follows: b

And each class/file that is included in the project, will be flagged according to the type of the class(QtMoc, QtUic, QtRcc): c

Probably this what gives the Qt VS Extension to identify how to treat each file, so if it's QtUic, then it would check if any changes in the .ui files are present, and if there are new changes, it would re-compile the ui file, then moc the class that belongs to the .ui file and only then re-compile the actual class that owns the .ui file.

In summary, is there any possible way to make CMake generate a project similar to one Qt VS Extension generated when I choose in CMake the VS generator? I'm guessing CMake doesn't support this internally, as they tend to abstract all this behavior to make all VS projects as generic as possible no matter what framework is used, but CMake does have flags to support Qt like:

set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTOUIC ON)
set(CMAKE_AUTORCC ON)

So I'm assuming it wouldn't be much of a work to implement.
Probably my best bet is to fork CMake and re-implement this behavior myself? psuedo example:

if CMAKE_AUTOMOC == ON & CMAKE_VS_EXT == ON
    Do some custom changes to the .vcxproj file
endif

Sorry for the long post, but any ideas and help would be greatly appreciated. Thanks!

  • Can you post the relevant part of your CMakeLists.txt where you try to handle the UI files and the MOC files? We always generate our solutions with CMake and did not notice this behaviour. – vre Feb 07 '19 at 16:32
  • I guess you can have a look here: https://github.com/giladreich/QtDirect3D/blob/master/src/demo/Direct3D9Widget/CMakeLists.txt But there is no handling on the consumer side, this all handled on CMake side(the way it generates the project files). –  Feb 07 '19 at 17:00
  • @vre Correct me if I'm wrong, but when you say you did not notice this behavior, you talking about the part where the changes on the UI's doesn't take place unless I rebuild my project? –  Feb 07 '19 at 17:11
  • CMake's generated VS solution does not run UIC or RCC or MOC automagically. It always happen on project rebuild. – vre Feb 07 '19 at 17:33
  • @vre Thanks for the advice. This is exactly why I think some further implementation needs to be done on CMake side to make it properly work with the Qt VS Addin, which work quiet well and very convenient to use. –  Feb 07 '19 at 17:40

1 Answers1

0

As it's too much (code) for a comment I put that an answer.

AFAIK you do not have to include the generated files to your add_executable call. That is something CMake automoc feature does behind the scenes.

A typical sequence in our CMakeLists.txt files look as follows:

include_directories(${CMAKE_CURRENT_BINARY_DIR})

file(GLOB_RECURSE SOURCES sources/*.cpp)
file(GLOB_RECURSE HEADERS include/*.h)
file(GLOB_RECURSE FORMS ui/*.ui)
set(CMAKE_AUTOUIC_SEARCH_PATHS ${CMAKE_CURRENT_SOURCE_DIR}/ui)
file(GLOB_RECURSE RESOURCES resources/*.qrc)

set(CMAKE_AUTOMOC TRUE)
set(CMAKE_AUTOUIC TRUE)
set(CMAKE_AUTORCC TRUE)

add_library(theLib ${SOURCES} ${HEADERS} ${FORMS} ${RESOURCES})

target_include_directories(theLib BEFORE
    PUBLIC
        $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
        $<INSTALL_INTERFACE:include/${PROJECT_NAME}>
)
vre
  • 6,041
  • 1
  • 25
  • 39
  • Thanks. The only reason I added the generated files(i.e ui_*.h etc..), because originally the Qt VS Addin does that, which is nice to have if you want to view what files has been generated. But as I said in my previous comment, I wish CMake would generate proper VS project to have better integration with the Qt Addin. –  Feb 07 '19 at 17:42