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

Missing support for PLUGIN_EXTENDS (qmake) and QT_PLUGIN_EXTENDS (CMake) with Qt static builds



    • Type: Bug
    • Status: Reported
    • Priority: P3: Somewhat important
    • Resolution: Unresolved
    • Affects Version/s: 6.0.4, 6.1.0, 6.2
    • Fix Version/s: None
    • Labels:


      In Qt5, each static plugin project can declare that it should be linked by default into an application, only if a certain Qt module is linked.

      This is done in the qmake project by setting the PLUGIN_EXTENDS variable. An example of that is the svg icon plugin and the cmake auto tests mock3plugin




         PLUGIN_EXTENDS = svg

      means the plugin will be linked if the application links against the QtSvg module and

       PLUGIN_EXTENDS = mockplugins1 mockplugins2

      means that the mock3plugin plugin will be linked if the application links either against Qtmockplugins1 or Qtmockplugins2 Qt modules.

      This is handled by qt.prf here https://github.com/qt/qtbase/blob/5.15/mkspecs/features/qt.prf#L85

      We tried to implement the same behavior for Qt5 cmake support, but it doesn't actually behave like that, we merely compare some property values.


      What we should do is check if the final CMake target links against a specific Qt module (the one in QT_PLUGIN_EXTENDS).

      This might be difficult to do because writing a genex like


      will not catch transitively linked Qt modules.

      This is alluded too by the comment at

      Now the Qt 6 part.

      pro2cmake didn't actually port qmake's PLUGIN_EXTENDS information to CMake, so we lost that information.
      Which means qt6 qmake projects will regress.
      And qt6 CMake projects don't handle any kind of PLUGIN_EXTENDS functionality at all.

      It's difficult to gauge how important of a feature that is. I suppose some qmake projects might break. At least that's the current state.

      We should at least restore the qmake behavior, which will mean creating some new API option for qt_internal_add_plugin and annotating all plugins with the lost information, so we generate correct qt_plugn_foo.pri files.

      Ideally we find a way to make it work with CMake, but that's probably less critical.


          Issue Links

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



              qtbuildsystem Qt Build System Team
              alexandru.croitor Alexandru Croitor
              0 Vote for this issue
              1 Start watching this issue



                  Gerrit Reviews

                  There are no open Gerrit changes