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 <[email protected]> wrote: > > > On May 31, 2018, at 15:47, Davide Coppola <[email protected]> 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 > [email protected] > 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>
_______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
