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

[Davide Coppola]

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.

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.

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...

I also noticed an abandoned Qt Creator plugin scripting project
<http://code.qt.io/cgit/playground/qt-creator/plugin-scripting.git/> in the
Qt repos. Any chance something like that will be restarted? Maybe using the
new/upcoming improved Python integration?

Cheers

[Carel Combrink]

Hi,

As the developer for the SpellChecker plugin[1] I am currently at a stage
where I only build releases as needed. This can be downloaded from the
release page [2].

Normally I only need to create a binary for the major.minor releases, then
it works on the patch releases as well.
This however failed for QtCreator v4.6.1, for some reason 4.6.1 could not
load my plugin built for 4.6.0.
In the past this was not an issue. Not sure why this happens.
(Perhaps something that I did wrong, something that caused it in QtC, any
information would be nice?)

I build for MSVC 32 and 64 bit, using MSVC compiler. Normally I try to just
build for the QtC version released along with the installers, trying to
match the Qt and compiler version.
I also build for Linux 64 bit, but normally only use the latest Ubuntu.
Based on some feedback I have also started building for Ubuntu 16.04 since
the last release for QtC 4.6.1.
I can't build plugins for MacOS since I do not own a Mac.

I have a general impression that most people use QtCreator from the
installers, thus I just build releases for those versions.
If someone build QtC themselves, I provide proper (I hope) steps for them
to build the plugin as well.

Building is currently a tedious process, but since I am not actively
developing the plugin I make releases only as QtC versions are released,
and then I just do it.
If I start developing more actively I will probably set up some CI builds
for the plugin.

For me this is working quite well at the moment.

[1] https://github.com/CJCombrink/SpellChecker-Plugin
[2] https://github.com/CJCombrink/SpellChecker-Plugin/releases

Regards,
Carel

Post by Davide Coppola
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.
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.
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...
I also noticed an abandoned Qt Creator plugin scripting project
<http://code.qt.io/cgit/playground/qt-creator/plugin-scripting.git/> in
the Qt repos. Any chance something like that will be restarted? Maybe using
the new/upcoming improved Python integration?
Cheers
--
*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
http://lists.qt-project.org/mailman/listinfo/qt-creator

[Eike Ziller]

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
***@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]

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

Post by Davide Coppola

Post by Davide Coppola
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.

Post by Davide Coppola
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
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.

Post by Davide Coppola
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.

Post by Davide Coppola
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?

Post by Davide Coppola
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).
- 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.

Post by Davide Coppola
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
http://qt.io
GeschÀftsfÌhrer: Mika PÀlsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B

[Carel Combrink]

Hi,

That is exactly the same error that I saw on Linux (and crash), on Windows
at least Qt Creator complained that it did not want to load the plugin (did
not crash)

Regards,

Post by 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
./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

Post by Davide Coppola

Post by Davide Coppola
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.

Post by Davide Coppola
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
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.

Post by Davide Coppola
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.

Post by Davide Coppola
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?

Post by Davide Coppola
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).
- 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.

Post by Davide Coppola
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
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
http://lists.qt-project.org/mailman/listinfo/qt-creator

[Eike Ziller]

Post by Davide Coppola
Thanks Eike and Carel for your replies.
./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.

Post by Davide Coppola
Cheers

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.

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).
- 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
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
***@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