the variable is later re-used by qtPrepareTool(), so the tools used to
build the tool would get excess variables passed.
Change-Id: Ib1bdd2211b4a8615e2be9ba0310822f373f5efb0
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
qtPrepareTool() does it anyway, so this saves repeated manipulations.
for now, this is just nicer, but soon it will be a requirement.
Change-Id: I5184e0e4597c6d5a4d7dd4cc4d81e7f742a79fc8
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
QFINDTESTDATA is already prepared to find it there.
Change-Id: I467392786ce6bcfbf1bd0b6079f60c9df06834b1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@theqtcompany.com>
A minimal device spec that can be used to build for arm devices.
Change-Id: I4c9949d8cc59ad534fc7617034f6beb40d6a987e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
If CROSS_COMPILE is set on a Debian multiarch platform, then PKG_CONFIG
should be set the same way as the other cross compilation tools.
Change-Id: Id359a6bbdcbf8a136a0268a82301fc086a2adcfe
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The qt_poll function calls recv to query whether fds marked by select
as readable should be marked POLLIN or POLLHUP in the pollfd structure.
On many platforms such as QNX this requires extra link-time libraries
which were not previously required by QtCore.
While the qt_poll function is intended as a fallback mechanism only for
those platforms which do not implement poll natively, the function was
compiled unconditionally whenever QT_BUILD_INTERNAL was defined, e.g.
in developer builds.
Additionally the function was included on those systems that define poll
in system headers so that configure determines build-time availability,
but do not define _POSIX_POLL > 0 or indicate POSIX:2008 compliance via
either the _POSIX_VERSION or _XOPEN_VERSION macros. On those systems a
sysconf query for _SC_POLL was performed to determine at runtime whether
to call the system poll or qt_poll.
Both of these cases are in fact counterproductive. In the first case the
sole consumer of the function is a single manual unit test. In the
second, to my knowledge no platform requires the runtime fallback.
Despite that, we were forcing an extra dylib in both cases.
Both cases are fixed by 1) moving the implementation into its own file
for the unit test to include and 2) dropping the dynamic fallback if
configure determines availability of poll at compile-time.
This also reverts commit 1377709711, which
added -lsocket for QtCore on QNX.
Change-Id: I2dd10695c5d4cac81b68d2c2558797f3cdabc153
Reviewed-by: James McDonnell <jmcdonnell@qnx.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
That implies we need to differentiate between a variable set but empty
and an empty variable. GCC, Clang and the Intel compiler accept -msse2
on 64-bit builds without warning (they also accept -mno-sse2), but the
Microsoft compiler does not have that option.
Change-Id: I54233388ba10994996ae3e749fd829085e8fd7b7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This should help improve the cleanliness of our source code, including
compliance with the C++ standards. They apply to all of our code except
examples (they don't load qt_common.prf).
Change-Id: Ia0aac2f09e9245339951ffff13c94663c1901766
Reviewed-by: David Faure <david.faure@kdab.com>
no idea why it was limited to linux. the variable is already empty on
platforms which don't support it anyway. also, for plugins, it's
consistently enforced as well.
Change-Id: I117f4988a2e301ca98cdc088188d6f8c44ea0ba5
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
qt5 qmake is perfectly capable of complex expressions on the LHS.
Change-Id: Ibf8c82a4aa1a419895c6012610269e1cc9ca93ab
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Whenever a qml plugin is made static, the qmldir and other related
files need to be compiled into the resources, so they can be found
in the import path. By using qrc:/qt-project.org/imports, we can
have this taken care of automatically for us via the build system,
leaving us to just ensure that it is initialized in the code.
Task-number: QTBUG-35754
Change-Id: Ifa7e2a66fd78dc6713dd7a8661ea2c155b174d35
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This is needed to be able to use Qt (with dynamic ANGLE) in a plugin
while the host runs a different version of Qt (and ANGLE).
In addition to changing the LIBEGL_NAME and LIBGLESV2_NAME variables
you also need to update the value of the LIBRARY definition in the
.def files for ANGLE:
qtbase/src/3rdparty/angle/src/libGLESv2/libGLESv2[d?].def
qtbase/src/3rdparty/angle/src/libGLESv2/libEGL[d?].def
Task-number: QTBUG-48431
Change-Id: Idd00d039ba3e20cc0ec7496bee36ed1c90383b0d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
Visual Studio version specific changes have been added to msvc-
desktop.conf which is not used in WinRT or Windows Phone related builds.
Hence take a similar approach to gcc and introduce msvc-base to be used
by all configurations for common settings.
For WinRT this will only be applied to msvc2015 and later on to not
introduce any regressions or behavior changes for previous versions.
Change-Id: Ib1a4d539d46d788470c00cb5969fee74a803bd67
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
don't install the module .pri file into qtbase even when doing a
non-prefix build.
this has no effect on modules built as part of a top-level build, as
they announce themselves via .qmake.super anyway.
however, modules built separately become unavailable unless QMAKEPATH
or QMAKEMODULES is set. this is deemed not relevant by the original
audience of this feature (the qtwebkit team).
Change-Id: I14c170b2c5dbb99608939aef1a541563d5b755d9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
longer term, the redundant .dlls from the libdir will hopefully
disappear. short term, this is a workaround for CI brokenness.
Change-Id: Ia30173355f3aca222d4ca40e7a38c2cf535bbc03
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
The xcodebuild tool only supports the install action for devices, not
for the iOS simulator platform.
Change-Id: I47e8bb7d44962bd4a433a314fa9d315ed3683ca6
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com>
The files are automatically generated, so that's where they
belong. This makes a small cosmetic difference when generating
Xcode projects, since then the files will be grouped under
a different folder in the project explorer, separate from user
sources.
Change-Id: Ic2599ccb3008635e76ae467eec80f2b9e5ca838e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
The platform is no longer supported or actively maintained, and is
in the way for improvements to the Unix event dispatcher and QProcess
implementations.
Change-Id: I3935488ca12e2139ea5f46068d7665a453e20526
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
qt_framework and {app,lib}_bundle imply darwin, so there is no point in
testing for it.
Change-Id: I9fe48c26c8e271a5575b17e92df8674d3c3a3204
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
CONFIG+=qt_framework is actually put into qconfig.pri, so it's always
set in framework builds. things (sometimes) worked only by virtue of the
qt_framework checks being in "else" branches of "static" checks. use
lib_bundle instead, which triggers the actual framework build anyway.
amends b72d1db44.
Change-Id: Ib725c43476d9fb38bad940ce09905d29ff3edfa3
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
While all apps need to have internetClient as a capability, the option
to provide further capabilities via qmake has been removed in the
template.
Instead we add the required items inside the prf and keep the manifest
template as generic as possible.
Task-number: QTBUG-49504
Change-Id: If26b9da277a5269a57b34e74c146b40b1b64d091
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Reviewed-by: Andrew Knight <andrew.knight@intopalo.com>
frameworks are currently broken anyway, and we don't create .pc files
for the private part of public modules, so creating them for entirely
private modules is just inconsistent.
Change-Id: I98da8def73d72ac69b9b246687dce6b1fd150f61
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Andy Nichols <andy.nichols@theqtcompany.com>
the projects which use full mode with the named modules have them.
Change-Id: I3b9383d1cc2b43411c25690a5e35e7e84a55aa23
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Andy Nichols <andy.nichols@theqtcompany.com>
the check whether a module depends on itself should be done by the code
which *builds* modules, not which *uses* them.
the check whether a plugin tries to use itself seems kinda pointless in
the first place, so just remove it.
Change-Id: I89b357dae7d7979d131b6824f197e7088047272f
Reviewed-by: Andy Nichols <andy.nichols@theqtcompany.com>
that way other modules can use the headers without hacks.
this required making the base directory for paths in headers.pri
configurable in syncqt.
Change-Id: Id35cfe05bcf4c576d3f2d0d8d09590a5e23d21d3
Reviewed-by: Andy Nichols <andy.nichols@theqtcompany.com>
there is nothing to link with it anyway.
Change-Id: I2e942d24bb39855b3682f3e8d85cb6abca75cb61
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
instead of building host tools always in debug mode, follow the overall
build type, and provide an option to override it.
this supersedes the pre-existing -optimized-qmake option.
however, that option never existed in the windows configure, and this
legacy continues as far as qmake is concerned (msvc builds of qmake are
always somewhat optimized, but not mingw builds).
Change-Id: I42e7ef1a481840699a8dffff13fec2626af19cc6
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Between the very latest images linking against kernel32.lib has been
forbidden. This is completely undocumented and only throws a "dependent
dll not found" error.
Instead we should link against OneCore for msvc2015, which can be used
for Windows 10 Desktop and Mobile.
Task-number: QTBUG-49349
Change-Id: I21d32a92dfd41548ca563d3e56c623a0cb297588
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
the statement order was wrong since c23a086e - we can't use
MODULE_DEPENDS before we define it.
but actually use a bigger cannon and partially revert the patch, to
include .depends unconditionally again. the idea is that this should
override a possibly included other .pri file from a previous
build/install. (the same argument would sort of apply to .envvars as
well, but we assume that its presence won't vary between builds.)
Change-Id: I95e9743e367a3d1f45d603d1bb5b31c4875f39a2
Reviewed-by: Giulio Camuffo <giulio.camuffo@jollamobile.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
Raspbian/Debian require a toolchain with the multiarch patches so we
need to add deb-multi-arch to the DISTRO_OPTS variable for pkgconfig to
work correctly. The Raspberry Pi 1 mkspec has this already and can be
used to build Qt for both versions of the Pi, but the Raspberry Pi 2
mkspec is missing this, and would not be usable in its current state for
building for Raspbian/Debian which is the most popular distro for the
Raspberry Pi.
Change-Id: I6a7a08059f9f91da524b5f51e0697115ef684f30
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
This separation makes it possible to make a
canadian cross build of Qt on a linux build machine.
The canadian cross build requires an external Qt that
runs on the build system.
Change-Id: Ifd83a4c6376d3299647e74bb349a3452a6f433fc
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Somehow qmake doesn't add the correct rules for the Android makefiles,
so the build fails when cross-compiling from Windows. The reason for
that is unknown (could be related to that "qt_android_deps" config, but
that isn't used anywhere in qmake or the buildsystem).
This isn't likely to be a problem, since there are no global installs of
Qt on Android.
Change-Id: I1d0f78915b5942aab07cffff140f95ce32324030
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qgltf is a tool provided by the Qt3D module that enables 3D assets to
be defined in qmake project files, and have them converted to an
efficient binary format at build time. The qmake feature will convert
all 3D assets specified by the QT3D_MODELS variable to the qgltf
format and add the new model asset to the project as a Qt resource
file.
Change-Id: If7250d6f23a06254b1ed0e408057723763aad8c8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This way, it's possible to tell which applications and libraries depend
on the Qt private API and of which Qt library. Linux distributions can
use this information to decide which applications need to be recompiled
every time Qt itself is rebuilt.
This is done by scanning all class and struct definitions in the private
headers (we've already got the list from syncqt). I opted to add a new
script instead of modifying syncqt because then this can run in parallel
with the rest of the compilation, as opposed to during qmake
time. Another advantage is that it catches modifications to the headers
in between qmake executions.
Since this is already Unix specific, it should be no problem to use Perl.
This solution is limited to use of non-inline symbols of classes
declared in private headers. It will not catch free variables (such as
qsimd_p.h's qt_cpu_features), use of inlined functions or just plain use
of a class/struct for accessing its data members. However, this is
already better than nothing and should help Linux distributions quite a
lot. And there's no way to catch the latter issue anyway.
Change-Id: I049a653beeb5454c9539ffff13e3fff36400ebbd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
