[Qt-creator] Qt Creator plugin distribution - best practices and future plans

[Davide Coppola]

Thanks Eike and Carel for your replies.

All you said makes sense, even if I have to confirm that when building my
plugin for 4.6.0 I can't run it with 4.6.1 as it crashes the program with
the following error:

./qtcreator: symbol lookup error:
/home/m3xican/.local/share/data/QtProject/qtcreator/plugins/4.6.1/libSIGBUILD.so:
undefined symbol: _ZN4Core12IOptionsPageC2EP7QObject

Not a huge deal, but apparently the backward compatibility was broken in
4.6.1

Cheers

On Fri, 1 Jun 2018 at 07:59, Eike Ziller <Eike.Ziller at qt.io> wrote:

>
> > On May 31, 2018, at 15:47, Davide Coppola <vivaladav at gmail.com> wrote:
> >
> > Hi,
> >
> > I am about to release a plugin for Qt Creator and even if I have no
> problem in releasing the source code, I would like to release binaries as
> well for quick installing.
> >
> > I have the impression that this is not an easy task as I should release
> a different binary per Qt Creator version and that wouldn't even cover all
> the combinations of application/compiler.
>
> Platform/compiler combinations that we use for our Qt Project prebuilt
> binaries are currently:
>
> MSVC2015 32&64 bit
> Linux / GCC 5.3(?) 64 bit
> macOS / Clang / 64 bit
>
> You also have to use a Qt version that is compatible with the Qt version
> that the prebuilt binary uses. (4.6 == Qt 5.10, i.e. it should work if you
> compile with Qt <= 5.10).
>
> You can find the detailed information on which compiler & Qt was used for
> a Qt Creator binary in its Help > About Qt Creator dialog.
>
> > For example a friend tested my plugin with the Qt Creator package
> provided by Arch Linux and it was crashing for him, likely because they
> build Qt Creator with gcc 7 and I built the plugin with gcc 5.4.
>
> I doubt that you’ll be able to create a single prebuilt binary that works
> on all Linux distributions. Already the locations and versions of standard
> libraries can differ, as well as Qt versions etc etc.
>
> > Are they any best practices or "standard" ways to handle this?
> >
> > Is there any plan from the Qt Creator developers to relax the version
> parity requirement?
> > Ideally I would like to build a plugin for 4.6 and have it running with
> all 4.6.x versions at least, instead of having to build it for 4.6.0,
> 4.6.1, etc…
>
> We try to keep patch releases _backwards_ compatible to the .0 release,
> and the version compatibility information reflects that (i.e. 4.6.1 states
> that it is compatible with 4.6.0).
> That means:
> - If you build your plugin against 4.6.0, it will run in 4.6.1 and 4.6.2.
> - If you build your plugin against 4.6.1, it will run in 4.6.2, but _not_
> in 4.6.0.
>
> > I also noticed an abandoned Qt Creator plugin scripting project in the
> Qt repos. Any chance something like that will be restarted? Maybe using the
> new/upcoming improved Python integration?
>
> We talked about the potential of PySide for platform independent plugins
> for Qt Creator recently, but we don’t have concrete plans for it yet.
>
> Br, Eike
>
> --
> Eike Ziller
> Principal Software Engineer
>
> The Qt Company GmbH
> Rudower Chaussee 13
> D-12489 Berlin
> eike.ziller at qt.io
> http://qt.io
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
>
>

-- 
*Davide Coppola*

*website:* http://www.davidecoppola.com
*blog:* http://blog.davidecoppola.com

<http://plus.google.com/+DavideCoppola>
<http://www.linkedin.com/in/davidecoppola>
<http://www.twitter.com/vivaladav>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20180605/90ce446a/attachment.html>