New AutoUIC generates files in a different place from CMake 3.8
Here's another really obscure change caused by the AutoUIC improvements; again I'm not sure this is worth fixing.
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>.hin $CMAKE_CURRENT_BINARY_DIR - CMake 3.9 generates
ui_<foo>.hin $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").