meta-qt5 layer now in oe-qky-src

A little over a week ago, I added the meta-qt5 layer to oe-qky-src, my fork of OpenEmbedded. However, it broke the build of some packages.

So, I went on a journey, exploring how to compile Qt5 without the meta-qt5 layer, from basic principles. A very intense several days, ended with frustration. Well, lots of frustration during those several days!

I did get it to build, using autotools only, but only for x86_64 host and x86_64 target. Kept getting errors when attempted cross-compile for aarch64 target.

Yesterday, gave up, and went back to the meta-qt5 layer, this time hunted down why it's introduction caused some other packages to fail.

Got it sorted, qt5 5.10.1 now builds, but have not yet ported any qt5-based apps into oe-qky-src. Did attempt Scribus, but got a compile error. For now, will build Scribus in the final running system.

This morning, tried to use Smartgit to commit the latest changes. Did something wrong... it seems, when committed a couple of files and a directory together, Smartgit got confused. Smartgit seems to be thinking that the 'meta-qt5' folder is a file!

Git is very powerful, but when something goes wrong, you can really get your knickers in a twist.

To get it uploaded, here it is as a tarball:

http://distro.ibiblio.org/easyos/project/oe/oe-qky-src/oe-qky-src-20180715.tar.gz

Expand somewhere, it will expand to folder 'oe-qky-src', and there is a readme inside.

Right, now to fix Smartgit...

EDIT:
OK, fixed. The problem was, folder meta-qt5 had a .git folder in it, which confused Smartgit. See commits for July 15, 2018:

https://github.com/bkauler/oe-qky-src/commits/master

EDIT 20180717:
I built EasyOS in woofQ from binary packages imported from oe-qky-src, then attempted to compile Scribus. Lots of configure errors. I found that .cmake files in /usr/lib/cmake are somewhat broken. They are setup to work inside OE. I have fixed them, the fixes are in the template files in woofQ, woof-code/packages-templates/qtbase, qttools, etc.

Interesting observation: cmake seems a lot more troublesome in a cross-compiling environment than autotools-based projects. This is an interesting observation due to the praise for cmake that I read everywhere, and some projects, such as Scribus going over to it.

Tags: oe