Upcoming Qt switch to OpenGL ES on arm64

[Steve Langasek]

On Wed, Nov 28, 2018 at 05:03:51PM +0300, Dmitry Shachnev wrote:
> On Tue, Nov 27, 2018 at 11:00:52PM -0800, Steve Langasek wrote:
> The amount of packages will probably be larger in the current sid,
> but it should not be more than 20 packages.

> Plus there are packages which are using QT_OPENGL_ES macro for conditional
> compilation (as I mentioned in my previous mail), but there are also not many
> of them:

> gammaray
> goldendict
> gst-plugins-good1.0
> kamoso
> krita
> leocad
> openclonk
> phonon-backend-gstreamer
> qtav
> qt-gstreamer
> qtwebkit-opensource-src
> qtwayland-opensource-src
> qtcharts-opensource-src

Right, and the fact that they can conditionally compile differently with
OPENGL_ES doesn't necessarily mean they would need to be.  E.g. looking at
gammaray, it's not obvious to me that this should have two builds; it's
possible the code should instead be fixed to not need to make this
conditional at build-time, given that the package is binary-compatible with
Qt built with or without GLES.

> > So perhaps someone in this thread is willing to put in this effort to
> > maintain 6 source packages, in order to avoid having to make a choice
> > between GL and GLES on arm64.

> I wonder if these can be new binaries in existing source packages, instead
> of separate source packages. Otherwise we will have too much code duplication,
> and also wasted time: for example, in qtbase-opensource-src, only src/gui
> needs to be built twice, and there is no need to built other submodules twice.

I would caution against prematurely optimizing for build-time.  Yes,
building the entire source package twice is a waste of resources, but it's
probably a drop in the bucket.

The reason not to build the two stacks from a single source package is that
the gl vs gles libraries are by design drop-in replacements for one another
- i.e.: they must have the same soname in order for the symbols magic to
work, which means they end up conflicting on the system.  You *could* design
a system that allows them to be coinstallable via subdirectories and
manually-managed symlinks, but I doubt this is actually worth it in practice
for the number of packages affected.

> We already have an example of double build inside the same source: on i386,
> src/corelib is built twice, with and without sse2 support.

> In any case, this task looks manageable.  Maybe if I have time someday I
> will take care of it, but in the meantime volunteers are welcome.



-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                   https://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-kde-talk/attachments/20181128/fd5987f3/attachment.sig>