Congratulations to our 2022 Qt Champions!

QPlugins - Workflow

  • I'm currently looking at using plugins for one of my applications. As (almost?) always the Qt documentation is very extensive and together with the examples it doesn't take long to get it actually working. However, my question is not about how the plugins work or how to use them but how to work with them.
    Apparently it makes sense (or is even necessary) that each plugin is a separate project and therefore has it's own .pro file. Is that correct? If so, how do you guys work with it? Do you open the main project and all related plugin projects at once in the QtCreator and hit the "compile all projects" button? Are there any tricks that you guys can share when working with plugins that simplify the life?

  • Moderators

    I do it the same way I do for any dynamic library + application code I'm developing:

    1. I create a session root directory in which all my projects will reside
    2. I create a session in Creator (it's basically what the solution in VS is)
    3. I add my application as a project, my library/ies as projects to this session (and under the session root directory)
    4. I set the projects' dependencies in Creator (if any, which you wouldn't have when working with plugins)
    5. I work - code, build, debug

    The only thing that I probably do a bit differently than the templates made from QtCreator is that I set a makefile name and I build everything (all the projects) in one directory (shadow building). When working with plugins I usually create a build subdirectory for the plugins alone. In the end it looks like this

    • /home/myuser/C++/sessionrootdir
      • project1 (contains the sources of project1 + the .pro file)
      • project2 (contains the sources of project1 + the .pro file)
      • and so on
      • bin (release build)
      • bin-debug (debug build)

    I find this most convenient, but there are certainly other ways of doing it. For example there can be subprojects set up (different targets) in a single pro, but I don't usually bother with this.

    Kind regards.

  • Lifetime Qt Champion


    If building an application with a custom set of plugins I usually use the SUBDIRS template with a structure similar to:

    myProject \
    ---- app(s)
    ---- libs \
    -------- myProjectLib
    ---- plugins \
    -------- myProjectPlugin1
    -------- myProjectPlugin2

    Then I ensure in the output of the various part of the project end up in a known structure e.g.

    shadow_build \
    ---- bin \
    ------- myApp
    ------- myLib.(so,dll,dylib)
    -------- plugins \
    ------------ myPlugin1.(so,dll,dylib)
    ------------ myPlugin2.(so,dll,dylib)

    Also one thing of importance (even if you have two different shadow build folder) is to add a suffix for the debug version of your outputs be it libraries, plugins and even application. That will avoid a lot pain trying to find out why your plugin can't be loaded and it's only a matter of debug vs release build. That's especially true if you build a plugin that might get into Qt's own sets of plugins.

  • Thank you very much guys, I appreciate it a lot. This definitely sounds like some good advice that I will follow.

    @SGaist You mentioned that I should have a suffix to distinguish the debug from the release build of a plugin. How would I do that? I assume that this is a setting in the project file?

  • Lifetime Qt Champion

    You can use TARGET = $$qtLibraryTarget(MyCoolLibrary)

  • Great, thank you very much!