Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-114563

Create a target-based CMake command as alternative to AUTOUIC and qt_wrap_uic

    XMLWordPrintable

Details

    • Suggestion
    • Resolution: Fixed
    • P2: Important
    • 6.8.0 FF
    • 6.5.1
    • Build System: CMake
    • None
    • All
    • 545b84b93 (dev)

    Description

      With CMake, there are several ways to handle Qt UI files.

      CMake's AUTOUIC has some bugs that don't seem fixable without user-breaking changes. Compare CMake upstream issues #16776 and #23523 to name just two.

      What AUTOUIC offers is currently:

      • users don't have to specify UI files in target sources
      • the #include "ui_form.h" statement in C++ sources triggers the generation of ui_form.h from form.ui

      We currently don't see a way to fix #16776 without requiring users to add UI files to target sources. That means one advantage of AUTOUIC is going to vanish anyway. Also, IDE users tend to want UI files in their target sources to have them visible in the project tree (#19513).

      Generating header files from Qt's UI files doesn't require magic from CMake (unlike moc). It would be possible to implement support for UI files purely in CMake language. There's already qt_wrap_uic, but that command is not target-based, and it doesn't allow multiple UI files of the same name.

      This suggestion is about creating a target-based CMake command for UI files.

      Requirements

      The functionality must allow for multiple UI files in different subfolders.

      It must be possible to specify additional arguments for uic per source file, per target (maybe initialized with a variable).

      AUTOUIC supports setting such options as INTERFACE for libraries. Compare INTERFACE_AUTOUIC_OPTIONS in the AUTOUIC documentation.

      There should be some convenient way to retrieve the include directory that's added to the target. Compare https://stackoverflow.com/questions/44746308/how-to-make-include-directories-added-with-autouic-available-to-downstream-targe/60203765#60203765 and #17456
      The use case for this are libraries that have an ui_form.h include in their headers (which is bad style, but whatever).

      possibility: qt_add_ui

      # CMakeLists.txt
      qt_add_executable(myapp main.cpp 
          aboutdialog.cpp aboutdialog.h
          mainwindow.cpp mainwindow.h
      )
      qt_add_ui(myapp 
          FILES dialogs/aboutdialog.ui mainwindow.ui
      )
      

      The following files are generated:

      ${CMAKE_CURRENT_BINARY_DIR}/.ui/ui_mainwindow.h
      ${CMAKE_CURRENT_BINARY_DIR}/.ui/dialogs/ui_aboutdialog.h
      

      This is added to the target's include path:

      ${CMAKE_CURRENT_BINARY_DIR}/.ui
      

      We mandate that include statements match the subdirectories:

      // aboutdialog.cpp
      #include <dialogs/ui_aboutdialog.h>
      
      // mainwindow.cpp
      #include <ui_mainwindow.h>
      

      possibility: use the target's sources

      Similar to the latter possibility with the difference that we don't add a new CMake command but handle UI files in the finalizer.

      qt_add_executable(myapp main.cpp 
          aboutdialog.cpp aboutdialog.h
          mainwindow.cpp mainwindow.h
          aboutdialog.ui mainwindow.ui
      )
      

      Here, the target finalizer checks the target's SOURCES and calls an internal command that does what's described for qt_add_ui.

      Disadvantages of adding this new command

      Already released Qt versions don't benefit from this. Unless we provide a compatibility file like suggested in QTBUG-114587.

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              orkun.tokdemir Orkun Tokdemir
              jbornema Joerg Bornemann
              Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes