QT needs to be compiled without the -r parameter from the qmake command
line. This is necessary to avoid those errors when building
qtdeclarative or qt3d without opengl for example:
Project ERROR: Unknown module(s) in QT: quick-private
or
Project ERROR: Unknown module(s) in QT: quick
Also update comments regarding the dependencies.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* e.g. maliit-framework-qt5 is staging sysroot specific paths in
sysroot-destdir/usr/lib/qt5/mkspecs/features/maliit-plugins.prf
sysroot-destdir/usr/lib/qt5/mkspecs/features/maliit-framework.prf
make sure they are replaced with correct ones on sstate reuse
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
This is set when generation an SDK, and thus would be usefull to have also
when bitbaking. That allows us to use this in *.prf files which is used
both when bitbaking as well as when using the SDK.
Signed-off-by: Anders Darander <anders@chargestorm.se>
(cherry picked from commit 96e8d29fdbdf6fa656c854d9b55c5b0c213166a7)
Acked-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Since the change to use a meta-environment canadian package in the
OE-Core, the SDK environment setting has been broken. This uses the
new subscript environment to fix it and also move the environment
generation to the nativesdk-qtbase recipe.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Fixes the following warning:
WARNING: PACKAGE_GROUP is deprecated, please use FEATURE_PACKAGES instead
Signed-off-by: Jacob Kroon <jacob.kroon@mikrodidakt.se>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
This adds a new image feature for easier remote debugging with
QtCreator.
The qtcreator-debug needs to be added as a valid item for image
features and having it inside the populate_sdk_qt5 is too late. User
will see a parser error as OE-Core images does not inherit the classs.
The possible workaround for it is to include it inside layer.conf file
until a kind of "bbclassappend" support is in place.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Tested-by: Giulian Vivan <giulian@ossystems.com.br>
The QtCreator is quite broken regarding finding the mkspecs files; so
to workaround it we must to add a symlink to it. The workaround was in
place but in the wrong sysroot, it must to be in the /native/ one.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Acked-by: Jonathan Liu <net147@gmail.com>
When looking for Qt5 headers we ought to use the Qt5 specific path. In
case the distribution wants to have a flat tree it can set QT_DIR_NAME
and it will still works as expected.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
When building nativesdk binaries we ought to rely in the native
mkspecs.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Acked-by: Denys Dmytriyenko <denys@ti.com>
This allow the toolchain generation using '-c populate_sdk' as it
includes the need host libraries into the SDK.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
:Release Notes:
Add optional Qt-Tools module.
:Detailed Notes:
Qt provide optional Qt-Tools like "lrelease", etc.
In absence of these tools one can not have i18n and l10n changes automated in build.
Adding "qttools-native" to "meta-qt5" Open Embedded layer provides those tools.
Using Qt-Tools i18n and l10n changes can be auomated.
:Testing Performed:
:QA Notes:
:Issues Addressed:
[GF-11028] Enable build of Qt localization tools in the Qt component
Change-Id: Ieb679249a05501a6ccb25108903a0fd48d4014f0
A cmake specific qt5 class which sets all required configuration parameters to
successfully compile cmake based applications.
Signed-off-by: Simon Busch <morphis@gravedo.de>
* qmake5_paths.bbclass refers to QT_DIR_NAME but it's defined on a higher level which
doesn't makes sense and breaks some use cases
Signed-off-by: Simon Busch <morphis@gravedo.de>
* qtdeclarative was using /usr/lib as HostLibraries causing
WARNING: QA Issue: qtdeclarative: The compile log indicates that host include and/or library paths were used.
Please check the log 'qtdeclarative/5.1.0-r0/temp/log.do_compile' for more information.
DEBUG 1: /OE/oe-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/qt5/mkspecs/features/qt_config.prf:23: QT_MODULE_HOST_LIB_BASE := /usr/lib
* also without this fix qtdeclarative and qtwayland are trying to
build tools against /usr/lib/libQt5Bootstrap.a (without sysroot
prefix)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* and move it to separate .bbclass which is easier to
replace in distro layer when you don't care about
conflicts with qt4
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* we're using QT_DIR_NAME subdirectory mostly to prevent conflicts with existing files from qt4
but setting it in all OE_QMAKE_PATH_* variables causes all apps which are just using qmake to
build to install e.g. in /qt5 which for stuff like qterminal or something doesn't
sound right (as long as there isn't qterminal4 and qterminal5 recipe)
* some variables are kept with default QT_DIR_NAME, e.g. qml, imports, plugins we can assume that
every application which installs some QML files will install them in location shared by all
* add qt5-native.inc which also adds this QT_DIR_NAME and common
inherits (later will be used also by qtwayland-native.inc)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* "${B}/*" in quotes doesn't match anything, better to remove whole directory
(incluing .files) and recreate it
* not sure why I've added quotes after testing first version, we don't
expect B with spaces.. but I'm a bit scared with rm -rf ${SOME_VAR}
after one glibc upgrade cleaned my whole disk and attached NFS array
when OLD_LOCALE_PATH wasn't detected correctly...
* qmake works well with separate B, use it by default
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* exports are still needed at least for qtbase configure script (which
is using our special eval variant of getQ(X)MakeConf functions
but maybe we should move them only to qtbase now
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* all variables should be now correctly set by qmake
* setting PARALLEL_MAKE in MAKEFLAGS can cause
PARALLEL_MAKE * PARALLEL_MAKE processes, because first
-j is applied on top level directory and then again in
each subdir, but it's faster then make -j PARALLEL_MAKE
only in top directory
* setting QMAKE breaks build in src/tools/bootstrap, because it
forces relative path bin/qmake which isn't correct
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* thanks to Mikko Levonmaa
* move it from qt5.inc to qmake5_base.bbclass, because it can be useful
for other apps too
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* makes it easier to change them, should be reused also in FILES_*
variables
* table of path variables and their different names available at
https://github.com/meta-qt5/meta-qt5/wiki/Building-with-OE
* all variables have OE_QMAKE_PATH_ prefix and then name from qmake
varaible
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* don't export it, let recipe decide where to call it or even if it
should be called (native recipes are not using it)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* otherwise sysroot from native build can leak to target build
* missing paths like Qml2Imports were defaulting to devault /usr/qml
* synchronize values between qt.conf and configure params
* using ${libdir}/${QT_DIR_NAME} is causing pkgconfig files to be
installed in this prefix too
* modify ArchData variable to move mkspecs files to qt5 prefix (so that
they don't conflict with qt4)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* it overwrites value set from shell env in qmake.conf and ar is loosing cqs params
mkspecs/linux-oe-g++/qmake.conf:QMAKE_AR = $(OE_QMAKE_AR) cqs
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* add linux-oe-g++ mkspec directly with patch
* add functions to read and eval OE_QMAKE functions from mkspec and
also export them with QMakeVar to be available also for config.tests
* add external-host-bindir parameter to skip building native tools
even when we're in fact cross-compiling (because we have them from
qtbase-native build already).
* use separated ${B} and ${S} and clean ${B} when reconfiguring
stalled qmake cache can be used when configure is reexecuted
cleaning ${B} prevents that and provide cleaner separation
* OE_QMAKE_AR cqs is added by Makefile, having it here too was causing
issues
* isEmpty(QT_EXTERNAL_HOST_BINS) doesn't work, so lets use exist()
even when it allows to incorrectly set wrong directory and build
native tools again (instead of skipping them)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* g++.conf and linux.conf were outdated a lot, lacking new options like
QMAKE_COMPILER causing a lot of warning like:
Project WARNING: qmake spec does not announce the compiler family. Guessed gcc.
* Instead of replacing whole common files, use custom qmake.conf which
overwrites common setting after including it
* different platform/xplatform can enable cross-compile build in upstream qmake
but that's not the same as what recipes are doing (upstream builds native tools
when bootstraping target qtbase, recipes build native tools with separate
qtbase-native and then want to skip building tools)
* still separate variables for both QMAKESPECs can be useful e.g. for
other native recipes
* quotes are needed, because some people have '-j 9' instead of '-j9'
* this can in theory cause PARALLEL_MAKE x PARALLEL_MAKE threads, because
MAKE itself is using PARALLEL_MAKE threads to run inner makes
* fix paralel build
* default make does good job, cleans mkspecs, installs all headers and
libs needed for qtjsbackend-native
* move native tools to QT_DIR_NAME prefix, this way qt4 and qt5 can be
staged at the same time
* only variables referencing WORKDIR are now QMAKE_PRL_BUILD_DIR
./x86_64-linux/usr/lib/libQt5Network.prl:QMAKE_PRL_BUILD_DIR = /OE/oe-core/tmp-eglibc/work/x86_64-linux/qt5-native/5.0.1-r0.0/qtbase-opensource-src-5.0.1/src/network/
./x86_64-linux/usr/lib/libQt5Xml.prl:QMAKE_PRL_BUILD_DIR = /OE/oe-core/tmp-eglibc/work/x86_64-linux/qt5-native/5.0.1-r0.0/qtbase-opensource-src-5.0.1/src/xml/
./x86_64-linux/usr/lib/libQt5Bootstrap.prl:QMAKE_PRL_BUILD_DIR = /OE/oe-core/tmp-eglibc/work/x86_64-linux/qt5-native/5.0.1-r0.0/qtbase-opensource-src-5.0.1/src/tools/bootstrap/
./x86_64-linux/usr/lib/libQt5Concurrent.prl:QMAKE_PRL_BUILD_DIR = /OE/oe-core/tmp-eglibc/work/x86_64-linux/qt5-native/5.0.1-r0.0/qtbase-opensource-src-5.0.1/src/concurrent/
./x86_64-linux/usr/lib/libQt5Core.prl:QMAKE_PRL_BUILD_DIR = /OE/oe-core/tmp-eglibc/work/x86_64-linux/qt5-native/5.0.1-r0.0/qtbase-opensource-src-5.0.1/src/corelib/
./x86_64-linux/usr/lib/libQt5Test.prl:QMAKE_PRL_BUILD_DIR = /OE/oe-core/tmp-eglibc/work/x86_64-linux/qt5-native/5.0.1-r0.0/qtbase-opensource-src-5.0.1/src/testlib/
./x86_64-linux/usr/lib/libQt5Sql.prl:QMAKE_PRL_BUILD_DIR = /OE/oe-core/tmp-eglibc/work/x86_64-linux/qt5-native/5.0.1-r0.0/qtbase-opensource-src-5.0.1/src/sql/
./x86_64-linux/usr/lib/libQt5DBus.prl:QMAKE_PRL_BUILD_DIR = /OE/oe-core/tmp-eglibc/work/x86_64-linux/qt5-native/5.0.1-r0.0/qtbase-opensource-src-5.0.1/src/dbus/
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* we also had PROVIDES for qt5-tools-native, this makes it a bit easier to see what is what
* drop FILESEXTRAPATHS, not needed after renaming to match BPN with qtbase patches
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Created new variables OE_CROSS_INSTALL_DATA and OE_CROSS_HOST_DATA
to support the installation and configuration of qtbase and dependant
modules.
Added paths for Qml2Imports
Signed-off-by: Mikko Levonmaa <mikko.levonmaa@gmail.com>
This allows the subsequent modules to install correctly. Also during
do_configure we stage target specific file into the staging area and
modify some prf files inorder to make the module (qt_lib_<module>.pri)
files install correctly
Signed-off-by: Mikko Levonmaa <mikko.levonmaa@gmail.com>
They are placed under STAGING_DATADIR as they need to be
kept separate from the native side. The reason for doing so
is that some qt modules require native tools and the mkspecs
in STAGING_DATADIR_NATIVE cannot be polluted with the target
mkspecs
There are still some packaging issues
Signed-off-by: Mikko Levonmaa <mikko.levonmaa@gmail.com>
The pri files get correctly placed under the work dir, but fail
to stage correctly. Also there are some packaging issues
Signed-off-by: Mikko Levonmaa <mikko.levonmaa@gmail.com>
