Unfortunately there is no way to disable running the Python/Jinja2-based
tests, so patch mesion.build in order to not fail in case of Python
dependency problems on the host.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Fix build errors on the noted platforms. Builds were failing with:
Package libmesa-amd is missing dependencies for the following
libraries:
libatomic.so.1
Signed-off-by: W. Michael Petullo <mike@flyn.org>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
strip '-' from PKG_NAME to determine official module name, but keep them
inside PKG_NAMEs for readibility (same as we still have the major
version number inside PKG_NAMEs)
This is trying to address the following issue: We pass variables to
qmake which get appended to qmake specific vars in mkspecs/*/qmake.conf.
However projects might invoke qmake once again, however without passing
respective variables along.
We might need to consider hard-coding the flags inside qmake.conf.
given qt5/common.mk is now included earlier, some variables such as
CONFIGURE_PREFIX are not yet defined. Since it's always /usr anyway,
set it statically.
qt5quick2-2d-sw-renderer-GLstubs was a hack back then to get QtQuick
running on hardware without native gles2 support, but isn't needed
for recent versions anymore.
That way projects not using qmake (but cmake) can still import all qt5
specific variables and helper functions, without its routines being
overriden by the qmake specific ones.
Under certain circumstances udev appears to be responsible (or part of)
a race condition, where input devices are treated and behave differently
than expected.
An attempt of documenting this issue:
https://bugreports.qt.io/browse/QTBUG-86630
They shouldn't be necessary, as nothing will or at least should link
against the resulting shared objects, as they aren't regular ones but
plug-ins.
However cmake-based projects complain about them missing - hence
provide/install them.
qmlplugindump appears to be called at the end of `make`-invocation for
qmake generated projects.
If it fails with exit code != 0 the OpenWrt build fails.
qmlplugindump is apparently needed as a host tool, but can not be
(easily) packaged as a host tool.
The project file states:
"qmlplugindump cannot be a build tool, because it loads target plugins."
which seems pretty mysterious to me.
So it's needed as a requirement on the host system, and/but natively
installed (newer) versions - at with my Debian's version - started to
fail with:
"QQmlComponent: Component is not ready"
I have no idea what qmlplugindump actually does or why it's needed.
It seems to do no harm to not invoke qmlplugindump - so
hack-not-even-fix it by just overriding each qmlplugindump invocation.
Without that patch the build rule including the input component depends
on other options being enabled, such as e.g. GUI support.
Since our host build is headless and we only need the input component
which actually does not have any such dependencies, we patch to force-
build it.
input component being present is a requirement for e.g. qt5tools
building certain host tools - such as 'kmap2qmap'.
