The one place for your designs
To enable design management, you'll need to meet the requirements. If you need help, reach out to our support team for assistance.
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").