On Tue, 5 Feb 2019 13:02:52 +0100 Charlene Wendling wrote: > 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.
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.
Charlène.
>
>
> > --
> > George Koehler <kern...@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
qt5.diff
Description: Binary data
