GitLab

Here's another really obscure change caused by the AutoUIC improvements; again I'm not sure this is worth fixing.

cmake-autouic.tgz

The tarball extracts to cmake-autouic/ and the CMakeLists.txt contains a little explanation. Both CMake 3.8 and 3.9 generate a build system, but the one generated by CMake 3.8 fails to build project2, and CMake 3.9 fails to build project3.

When auto-generating UI headers from <foo>.ui,

• CMake 3.8 generates ui_<foo>.h in $CMAKE_CURRENT_BINARY_DIR
• CMake 3.9 generates ui_<foo>.h in $CMAKE_CURRENT_BINARY_DIR and in _autogen/include/ ; the latter with the full path to the UI file as it is #included from C++ source

Consider normal use how you refer to the generated header, assuming you have done include_directories($CMAKE_BINARY_DIR):

• In CMake 3.8, #include "rel/path/to/current/bindir/ui_foo.h" will find it, since the header is generated in the current binary dir, and autouic only looks at the last part of the path.
• In CMake 3.9, the same applies.

But now consider a UI file in a subdirectory, referred to via a relative path in CMake:

• CMake 3.8 still generates it in $CMAKE_CURRENT_BINARY_DIR
• CMake 3.9 does, too, but also in a slightly different path, because it includes the full path to the UI file

Now including the file from C++ works differently:

• In CMake 3.8 you must use the include to current bindir, since that is where the file is generated
• In CMake 3.9 the source UI lives in a subdirectory, so you must provide the full path (relative to the AutoUIC search path, at least) to the UI file, otherwise AutoUIC won't find it.

So depending on your CMake version, the C++ code must use different #include paths to refer to the UI headers -- one with the full relative path, the other with the relative path to the current (list) directory.

The example tarball demonstrates this more clearly, I hope.

Since this is another one of those weird edge cases where "don't do that then" might be a viable answer, this is probably something for the documentation, although for the life of me I don't know how to write this down (perhaps "overly convoluted autoUIC setups are known to fail when moving to newer CMake").