> On 5. Jun 2018, at 15:32, Davide Coppola <[email protected]> wrote: > > 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
Indeed. Very sorry about that. We should look into at least half-automated testing for this in the future. > 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 -- 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 _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
