Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
CMake
CMake
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 3,183
    • Issues 3,183
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 15
    • Merge Requests 15
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • External Wiki
    • External Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • CMake
  • CMakeCMake
  • Issues
  • #17168

Closed
Open
Opened Aug 14, 2017 by Adriaan de Groot@adridgContributor

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.

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").

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
3.9.2
Milestone
3.9.2 (Past due)
Assign milestone
Time tracking
None
Due date
None
Reference: cmake/cmake#17168