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>
* 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>
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>
Otavio Salvador
Simon Busch
Martin Jansa
Mikko Levonmaa
Mikko Levonmaa