x11/qt5/{qtgraphicaleffects,qtquickcontrols*} when not x86

[George Koehler]

This mail is about the OpenBSD ports of
- x11/qt5/qtgraphicaleffects
- x11/qt5/qtquickcontrols
- x11/qt5/qtquickcontrols2

These ports work on amd64 and i386, but are broken on aarch64,
powerpc, and probably other platforms. Each port has .qmlc files in
its PLIST. Each port runs qmlcachegen (from x11/qt5/qtdeclarative)
to build .qmlc files from .qml files, but this tool writes machine
code (like x86 or x86-64 code) and gets disabled in other platforms.
Each port fails in the package phase if the .qmlc files don't exist.

From the (arm64) aarch64 bulk of 3 Feb 2019:
> http://build-failures.rhaalovely.net/aarch64/2019-01-31/x11/qt5/qtgraphicaleffects.log
> http://build-failures.rhaalovely.net/aarch64/2019-01-31/x11/qt5/qtquickcontrols,-examples.log
> http://build-failures.rhaalovely.net/aarch64/2019-01-31/x11/qt5/qtquickcontrols2.log

From the (macppc) powerpc bulk of 4 Feb 2019:
> http://build-failures.rhaalovely.net//powerpc/2019-01-12/x11/qt5/qtgraphicaleffects.log
> http://build-failures.rhaalovely.net//powerpc/2019-01-12/x11/qt5/qtquickcontrols.log
> http://build-failures.rhaalovely.net//powerpc/2019-01-12/x11/qt5/qtquickcontrols2.log

I found some logic in qt5/qtdeclarative in
WRKSRC/src/qml/jsruntime/qv4global_p.h that defines V4_ENABLE_JIT
on some platforms. I suspect that qmlcachegen uses the JIT to
write .qmlc files, but I am less than sure.

The JIT is enabled if:
- we are x86 or x86-64 and an OS in a list including OpenBSD.
- we are arm 32-bit, and something about Thumb is true, but I don't
know whether it is true in OpenBSD.
- we are arm 64-bit, but only for Linux or QNX, not for OpenBSD.
- we are mips 32-bit and Linux.

From this, I guess that qmlcachegen on OpenBSD can write .qmlc files
only for i386 or amd64.

When a qmake project does `CONFIG += qmlcache`, it checks if
qmlcachegen can target this platform. If not, qmake outputs a line,
> Project MESSAGE: QML cache generation requested but target
> architecture ***** is not supported.
where ***** is a name like "arm64" or "power". You can see this line
in dpb's .log files.

If you have installed qtdeclarative, and you know your own QT_ARCH
(see /usr/local/lib/qt5/mkspecs/qconfig.pri), then you can run

$ /usr/local/lib/qt5/bin/qmlcachegen --target-architecture ***** \
> --check-if-supported; echo $?

In my amd64 vm, where QT_ARCH = x86_64, it echoes 0 so .qmlc is
supported. In my macppc machine, where QT_ARCH = power, it echoes 1
so .qmlc is not supported. You can only check your own arch,
because qmlcachegen might not cross to other arches.

The fix might be to move .qmlc files from PLIST to PFRAG.qmlc, but
I have not yet tried to do so.

--
George Koehler <ker...@gmail.com>

[Charlene Wendling]

Hi!

On Tue, 5 Feb 2019 00:02:15 -0500
George Koehler wrote:

> This mail is about the OpenBSD ports of
> - x11/qt5/qtgraphicaleffects
> - x11/qt5/qtquickcontrols
> - x11/qt5/qtquickcontrols2
>
> These ports work on amd64 and i386, but are broken on aarch64,
> powerpc, and probably other platforms. Each port has .qmlc files in
> its PLIST. Each port runs qmlcachegen (from x11/qt5/qtdeclarative)
> to build .qmlc files from .qml files, but this tool writes machine
> code (like x86 or x86-64 code) and gets disabled in other platforms.
> Each port fails in the package phase if the .qmlc files don't exist.

Yes, there are *.jsc as well with the same problem.

landry@ gave me some hints, we could use the QML_DISABLE_DISK_CACHE
environment variable and disable all those cache files everywhere. But
according to the Qt people, there will be a performance drawback [1] if
we do it that way.

> From the (arm64) aarch64 bulk of 3 Feb 2019:
> > http://build-failures.rhaalovely.net/aarch64/2019-01-31/x11/qt5/qtgraphicaleffects.log
> > http://build-failures.rhaalovely.net/aarch64/2019-01-31/x11/qt5/qtquickcontrols,-examples.log
> > http://build-failures.rhaalovely.net/aarch64/2019-01-31/x11/qt5/qtquickcontrols2.log
>
> From the (macppc) powerpc bulk of 4 Feb 2019:
> > http://build-failures.rhaalovely.net//powerpc/2019-01-12/x11/qt5/qtgraphicaleffects.log
> > http://build-failures.rhaalovely.net//powerpc/2019-01-12/x11/qt5/qtquickcontrols.log
> > http://build-failures.rhaalovely.net//powerpc/2019-01-12/x11/qt5/qtquickcontrols2.log
>
> I found some logic in qt5/qtdeclarative in
> WRKSRC/src/qml/jsruntime/qv4global_p.h that defines V4_ENABLE_JIT
> on some platforms. I suspect that qmlcachegen uses the JIT to
> write .qmlc files, but I am less than sure.
>
> The JIT is enabled if:
> - we are x86 or x86-64 and an OS in a list including OpenBSD.
> - we are arm 32-bit, and something about Thumb is true, but I don't
> know whether it is true in OpenBSD.
> - we are arm 64-bit, but only for Linux or QNX, not for OpenBSD.
> - we are mips 32-bit and Linux.
>
> From this, I guess that qmlcachegen on OpenBSD can write .qmlc files
> only for i386 or amd64.

The implied code called by WRKSRC/tools/qmlcachegen/qmlcachegen.cpp
[2] can be found in WRKSRC/src/qml/jit/qv4isel_masm.cpp [3]. I was more
optimist than you are and i tend to trust your reading more than
mine :)

> When a qmake project does `CONFIG += qmlcache`, it checks if
> qmlcachegen can target this platform. If not, qmake outputs a line,
> > Project MESSAGE: QML cache generation requested but target
> > architecture ***** is not supported.
> where ***** is a name like "arm64" or "power". You can see this line
> in dpb's .log files.
>
> If you have installed qtdeclarative, and you know your own QT_ARCH
> (see /usr/local/lib/qt5/mkspecs/qconfig.pri), then you can run
>
> $ /usr/local/lib/qt5/bin/qmlcachegen --target-architecture ***** \
> > --check-if-supported; echo $?
>
> In my amd64 vm, where QT_ARCH = x86_64, it echoes 0 so .qmlc is
> supported. In my macppc machine, where QT_ARCH = power, it echoes 1
> so .qmlc is not supported. You can only check your own arch,
> because qmlcachegen might not cross to other arches.
>
> The fix might be to move .qmlc files from PLIST to PFRAG.qmlc, but
> I have not yet tried to do so.

What can i say is that i was able to run lxqt on macppc without any
issues without these cached files.

I had the same idea initially, but sthen@ proposed a better (imho)
alternative, introducing a MODQT5_COMMENT the same way Python does it
with MODPY_COMMENT, so we don't have to use PFRAGs.

I've packaged successfully these 3 ports with the diff i'm attaching but
reversed the conditional since then, according to your findings.

This hasn't been tested elsewhere that on macppc for now, and i needed
to do a make clean=plist before make package. I can't guarantee it's
perfect, but i felt like it was time to share it, to avoid duplicating
our work.

Charlène.


> --
> George Koehler <ker...@gmail.com>
>


[1]
https://blog.qt.io/blog/2019/01/11/qt-5-12-lts-road-faster-qml-application-startup/
[2]
https://github.com/qt/qtdeclarative/blob/ba6de61acd3129ad1435f6bca7f564385212f95c/tools/qmlcachegen/qmlcachegen.cpp
[3]
https://github.com/qt/qtdeclarative/blob/5.9/src/qml/jit/qv4isel_masm.cpp#L1645

[Charlene Wendling]

My change to SUBST_VARS made VERSION not being expanded, actually
breaking packaging with the other x11/qt5 ports includig ${VERSION}
in PLISTs.

I'm joining a new diff that fixes that on my macppc and amd64 machines.