Some Qt build tools may depend on QtGui, which need platform plugins
for running them. Use minimal platform plugin since no interaction
with the tool is expected.
Add PACKAGECONFIGs that can be used to enable gui and image format
plugins for the native and nativesdk builds.
Signed-off-by: Samuli Piippo <samuli.piippo@qt.io>
A wildcard not put between quotes is expanded by bash. If files matching
the pattern are found in the source directory then the find command is
non-sense and fails.
This commit put those search patterns in quotes and fixes the
installation of some recipes.
Signed-off-by: Florent Revest <revestflo@gmail.com>
All 3rdparty libs and includes are now resolved into full filepaths,
which means build paths to the yocto build environment are in module's
prl, pri, pc and cmake files.
Move existing patching from qtbase to the bbclass so that it's applied
to all modules. -L paths are no longer included in the .pc files, remove
unneeded patching for those.
Task-number: QTBUG-72903
Change-Id: Iae5d150593aef153c46aaf8a3ba22fbafcc9b818
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Mikko Gronoff <mikko.gronoff@qt.io>
Signed-off-by: Mikko Gronoff <mikko.gronoff@qt.io>
QMAKE_COMPILER is not meant to be the actual compiler, but a compiler
type (gcc, clang, mingw). For both mkspecs it's already set in the
common includes. Remove wayland and debug settings from the clang
mkspec as they are already removed from the gcc mkspec.
Signed-off-by: Samuli Piippo <samuli.piippo@qt.io>
The build-in qmake settings point to the sysroots on the host machine.
Running qmake on the target hence errors with:
Could not find qmake configuration file linux-oe-g++.
Error processing project file
So add qt.conf to the target image with the correct locations.
Signed-off-by: Jeroen Hofstee <jhofstee@victronenergy.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
This was never defined for nativesdk, which then broke sdk which
had nativesdk-qtwayland included. Rather than add it there, remove
its use everywhere, since it was not adding anything meaningful to
the build.
Signed-off-by: Samuli Piippo <samuli.piippo@qt.io>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Different HostPrefix was used when building Qt and in external
SDK's qt.conf. This caused e.g., wrong path in qmodule.pri for
PKG_CONFIG_EXECUTABLE.
Task-number: QTBUG-63097
Signed-off-by: Samuli Piippo <samuli.piippo@qt.io>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
We can not piggy back clang anymore on existing
OE mkspecs since starting 5.9 the configure is
asking compiler for include paths and it needs to
know if platform is clang-linux or g++-linux
Fixes:
ERROR: failed to parse default search paths from compiler output
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* adapt QtWebEngine recipe to use GN instead of GYP
* add QtRemoteObjects and QtWebView as a new Qt modules
* update available QtBase configure arguments
* remove obsolete patches
* patch all .pc files to remove build paths
* include generated QML cache files in packages
* the patch "configure paths for target qmake properly" could not
be applied anymore and support must be done differently
* QtWebEngine now requires gcc-multilib to be installed on the host
system, because the host tools are built to the same bitness as
the target (arm -> x86, aarch64 -> x86-64)
* refresh the patches to match with b5.9* branches on:
https://github.com/meta-qt5/qtbasehttps://github.com/meta-qt5/qtwebengine
and 56-based branch on
https://github.com/meta-qt5/qtwebengine-chromium
Signed-off-by: Samuli Piippo <samuli.piippo@qt.io>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Qt update to 5.8 caused fallout in meta-qt5-extra. It turned out that
qmake pulled in many pointers to native sysroot. Native sysroot is qmake's
default in case no configuration file qt.conf is set.
The problem with the new way of setting qt.conf by cmd parameter is that is has
to be set explicitly. For instance all the packages coming from [1] use
autotools for configuration. These ask qmake for paths during configuration
and build further Makefiles during compile. To patch these for additional cmd
parameter is nasty business.
Setting qt.conf when building all qtbase's causes errors during configuration.
To fix this we set the filename to a non existent file so that Qt's default is
used. This dirty hack was necessary because there was no way found to export
an empty variable OE_QMAKE_QTCONF_PATH.
This patch was tested by building huge parts of meta-qt5-extra. The meta-layers
did not yet contain oe-core's recipe-specific-sysroot changes so master build
might fail for missing dependencies.
[1] http://www.rncbc.org/drupal/
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
The linux-oe-g++ mkspec is changed to use $$(...) operator to obtain
the contents of an environment value when qmake is run instead of when
Makefile is processed. All OE_QMAKE_xxx variables need to be exported
for qmake to find them. configure's setBootstrapVariable function needs
to change $$(..) to normal $(...) operator to work with qmake's Makefile.
qt.conf generation for qtbase recipes is not needed, as configure will
generate its own version based on configure arguments. Skip running
qmake, since configure is now automatically invoked when it's run in
qtbase's root folder.
Update PACKAGECONFIGs for qtbase to match current configure options.
The new Qt configuration system [1] can be used with a new variable
EXTRA_QMAKEVARS_CONFIGURE, which takes both command line and feature
arguments.
Merge the two qtwayland recipes to one that supports all three targets
(target, native, nativesdk) without need for additional patch.
Recipes for new Qt modules: QtSCXML, QtNetworkAuth, QtGamepad.
Removes qtdeclarative-render2d
[1] https://www.mail-archive.com/development@qt-project.org/msg25257.html
Change-Id: Ib37c4d7323e8b45aa2b171e8427b6ec15aaee213
Signed-off-by: Samuli Piippo <samuli.piippo@qt.io>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Makes it possible to install qmake into ${bindir} without setting
QT_DIR_NAME = "".
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* LIC_FILES_CHKSUM were changed because of this small change:
commit 4343c4e731c3268614fc79c9c42b4e5e4d59d7e6
Author: Sze Howe Koh <szehowe.koh@gmail.com>
Date: Tue Jun 14 19:12:35 2016 +0800
Expand license scope from "Qt GUI Toolkit" to "Qt Toolkit"
* -no-nis option was removed from qtbase in:
commit 644d0e75240811212ed9fd0c21e3bd05db3ba5db
Author: Ralf Nolden <nolden@kde.org>
Date: Fri May 20 22:03:39 2016 +0200
Cleanup NIS support leftover from Qt 3/4
* allow to disable eglfs independently from gles2, because eglfs-egldevice
may be autodetected when libdrm was built before qtbase since this
upstream commit:
commit 5c6d27b8dfa695ab04766a1711b00421dba9c7d0
Author: Ralf Nolden <nolden@kde.org>
Date: Tue May 17 12:38:44 2016 +0200
Make eglfs-egldevice check work with pkgconfig as well
and then it fails to build, because libdrm could be removed from sysroot
and drm.h is missing.
* recipes-qt/qt5/qtquick1/0001-qdeclarativetextinput-update-to-match-QWidgetLineCon.patch
was resolved in upstream commit:
commit 26229cfa0b729313893af5674d604e8692dbb946
Author: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com>
Date: Tue Apr 26 15:08:34 2016 +0200
QDeclarativeTextInput: update API to use setBlinkingCursorEnabled
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* this requires latest oe-core (Yocto 2.1), if you want to use latest
meta-qt5 with older oe-core, you need to backport this bbclass
and more importantly don't forget to provide
EXTRA_CONF_PACKAGECONFIG
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
* they reference workdir and trip sanity check:
ERROR: QA Issue: libQt5Sql.la failed sanity test (workdir) in path qtbase/5.5.99+5.6.0-alpha1+gitAUTOINC+f7f4dde80e-r0/sysroot-destdir//usr/lib [la]
* I'm intentionally not using remove-libtool.bbclass recently
added to oe-core, because many people combine newer meta-qt5
with older oe-core and can be missing this bbclass, I've
pending patch to migrate this to remove-libtool.bbclass, will
probably merge it after 2.1 or 2.2 release.
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
When `QT_DIR_NAME` is defined as an empty string (default is "qt5"),
package.bbclass will throw lots of QA warnings because now the paths contain
double slashes ("//").
We can address these warnings by explicitly defining a slash in the
variable itself.
Signed-off-by: Adam YH Lee <adam.yh.lee@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
qmake5_paths.bbclass refers to QMAKE_MKSPEC_PATH_TARGET which is not
defined when inheriting qmake5_paths directly instead of qmake5_base.
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Change qmake.bbclass to support building native and nativesdk packages,
so that qmake or qt5-module can be inherited and BBCLASSEXTEND used to
create native and nativesdk packages.
qtxmlpatterns and qtdeclarative native and nativesdk modules are required
for Qt Quick Compiler.
Signed-off-by: Samuli Piippo <samuli.piippo@theqtcompany.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
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>
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
