CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-08-16T11:25:38-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/17168New AutoUIC generates files in a different place from CMake 3.82017-08-16T11:25:38-04:00Adriaan de GrootNew AutoUIC generates files in a different place from CMake 3.8Here's another really obscure change caused by the AutoUIC improvements; again I'm not sure this is worth fixing.
[cmake-autouic.tgz](/uploads/ecd2c0921393b00137233a74264be088/cmake-autouic.tgz)
The tarball extracts to cmake-autouic/ a...Here's another really obscure change caused by the AutoUIC improvements; again I'm not sure this is worth fixing.
[cmake-autouic.tgz](/uploads/ecd2c0921393b00137233a74264be088/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 <project>_autogen/include/ ; the latter with the full path to the UI file as it is `#include`d 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").3.9.2Sebastian HoltermannSebastian Holtermann