AUTOUIC: Ninja needs two passes to correctly build Qt project

In a Qt project on Windows with set(CMAKE_AUTOUIC ON) and using the Ninja generator I experience that if a foo.ui is touched I need to build twice with Ninja. The first time ui_foo.h is produced. The second time foo.cpp is compiled (presumably because ui_foo.h is updated) and the program linked. With MinGW Makefiles foo.cpp is compiled the first time around. This is with CMake 3.7.2. This has been reproduced on Linux as well on master.

changed title from Ninja generator needs two passes to correct build Qt project to AUTOUIC: Ninja generator needs two passes to correct build Qt project

Cc: @sebholt

added area:autogen gen:ninja labels

changed title from AUTOUIC: Ninja generator needs two passes to correct build Qt project to AUTOUIC: Ninja needs two passes to correctly build Qt project

mentioned in commit sebholt/cmake@4b7a9e69

mentioned in commit sebholt/cmake@8e3c996a

mentioned in commit sebholt/cmake@4d90919f

mentioned in commit sebholt/cmake@73851253

mentioned in commit sebholt/cmake@fe3918ce

mentioned in commit sebholt/cmake@6cec8d16

mentioned in commit sebholt/cmake@26a181d3

mentioned in commit sebholt/cmake@c2c91ff6

mentioned in commit sebholt/cmake@0197c453

mentioned in commit sebholt/cmake@0a106e53

mentioned in commit sebholt/cmake@203ee011

mentioned in commit sebholt/cmake@c8f92db7

mentioned in issue #17959 (closed)

This is still a problem with CMake 3.13.2 on Arch Linux.

After changes to a .ui file, I have to run ninja twice or else the build fails after significant changes to .ui files.

Steps to reproduce:

1. mkdir build && cd build
2. cmake -GNinja ..
3. ninja -v
4. touch *.ui
5. ninja -v

Expected results: autogen is redone and the .ui file change is applied.

Actual result: autogen is executed, but no further changes happen. Need to run ninja again.

Example small project for reproduction: demo.tar.gz

@Lekensteyn thanks for the example. I'm able to fix the dependencies by manually hacking the generated build.ninja file:

-build CMakeFiles/main_autogen main_autogen/mocs_compilation.cpp: CUSTOM_COMMAND
+build CMakeFiles/main_autogen main_autogen/mocs_compilation.cpp main_autogen/include/ui_mainwindow.h: CUSTOM_COMMAND

The main_autogen/include/ui_mainwindow.h file needs to be listed as an output of the build statement that generates it. Inside CMake's source this means the autogen infrastructure needs to list it as an output (or perhaps byproduct if it is meant to be copy-if-different) of the relevant custom command.

added triage:mr-welcome label

assigned to @sebholt

I'll have a look at this.

Oh well, I just discovered that ninja-build != ninja-ide...

Given the .ui file is listen in the target sources, we can compute the (default) ui_*.h file position. The ui_*.h file then can be appended to the outputs of the _autogen target (like @brad.king suggested). I tried this and it seems to work. It has limitations though.

• the (changing) .ui file must be listed in the target sources (not a too unreasonable demand IMO)
• the ui_*.h must be included as #include "ui_*.h" without a path like #include "<some>/<path>/ui_*.h"

We might address the <some>/<path> scenario by introducing a .ui source file property AUTOUIC_BUILD_PATH that must be set to <some>/<path>. This is an viable but uncomfortable solution because the user would have to add information that technically is available in the sources already. Only it isn't at configuration time or at least it isn't static since <some>/<path> might change.