In qtbase commit 7ac58d1ff0 (Make cmake
packages installed to /usr non-relocatable., 2013-02-11), we made
cmake config files non-relocatable if they were installed to
the /usr prefix. That was assumed to mean that this was a distro
or platform package, and was a workaround for the usr-move problem
on Fedora and ArchLinux.
However, cmake bug http://public.kitware.com/Bug/view.php?id=14041
showed that forcing absolute paths in this situation is not desirable
in cross compiling scenarios. CMake commit 6c613b433c45efb0bb013a6bd668cbb8ac740259
(Handle usr-move without forcing absolute paths (#14041), 2013-04-03)
addressed the problem in CMake, and this commit is an equivalent.
Change-Id: I065a6230bc618aa980fae6ca511ae10df4cd62c2
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
We now use an absolute path, to prevent picking up the wrong plutil binary.
In addition we pipe the possible stderr output of plutil and xpath to the
null device, so that the final QMAKE_MAC_PLATFORM_NAME will be empty in
case of any errors, and caught by the isEmpty() check below.
Change-Id: I8ad24bf63162a76410c2ae223dd2fc48e7886bbf
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This way, the default generator is used when cross compiling
for mingw.
Change-Id: Ie536f1bca35ea38aec1232cdd95fc063c4f23e70
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Reviewed-by: Peter Kümmel <syntheticpp@gmx.net>
The property only needs to contain the direct include dirs of
a target. For example, Qt5::Gui does not need to contain the
include/QtCore directory because it already has Qt5::Core in
its LINK_INTERFACE_LIBRARIES.
Change-Id: I69612f42c29e6056b3d15399498d041d43a0dd6b
Reviewed-by: Brad King <brad.king@kitware.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
It should also have an effect for Visual Studio project files, not
just makefile generators.
Change-Id: I395071f09b29a6e8967a3d44e41d30480ae783f7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
We always use the xcodebuild/xcrun/xcode-select binaries in /usr/bin,
as these will dispatch to the right binary based on what Xcode version
has been chosen using xcode-select -switch. This fixes an issue where
a tool was in the path from another Xcode installation. We can rely on
the tools as they are present on a clean Mac OS install.
Change-Id: I1d3cc1e92604f9be6d6f14639cb6322234edd696
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
xcrun will spit out errors to stderr and nothing to stdout if it fails
to find the tool in question. By checking for an empty return value and
skipping the sysrooting we guard against mangling the tool variable.
Change-Id: I68f59a6c8116696dd75cceed7b33ac666f3468b2
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
These are the same for normal builds, but differ when cross-compiling Qt.
Change-Id: I75eccc6f4b67b440a08c4aba41aabb7df686c9f9
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
This means we have to bump the deployment target to Lion (10.7), as the
LLVM 'libc++' C++ standard library does not support Snow Leopard (10.6).
For iOS the deployment target has to be bumped from 4.3 to 5.0, but we
don't enable C++11 by default yet as it's not tested enough on iOS.
Users who wish to deploy to 10.6 need to build their own Qt,
passing -no-c++11 to configure.
Change-Id: I7b5d20ab002db889d1091a4b7ff600f62caa7f06
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Change-Id: I1d8061302fbb8494b5ae31e20a644745fe969f10
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Brad King <brad.king@kitware.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
These variables are set by the ConfigVersion.cmake file already,
so no need to maintain them manually in the Config file too.
Change-Id: I73d949fb22052f4f6acbc1f70518e73f8fbf7c9c
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Fedora uses configure options to set the install prefix to a location
which does not contain the cmake config files. Rather than finding
dependencies from the installation prefix, find them in sibling directories
instead.
Change-Id: I06974e9655d0dda2a18064d0f9a33997cf2cb2d3
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Need to look in <android-sdk>/platform-tools/lib for dx.jar
Change-Id: I104cf157ce1795e907cca31b37c62163248b8d77
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
It's written to qmodule.pri by configure with a hard-coded path,
and hence need fixing up or appending, depending on which
exclusive builds are used.
Change-Id: I069c04438dc303868a76349c9bdd385adc074c0a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Extra-compilers such as objective_c.prf may reference QMAKE_CXX, so we
need to sysroot it before it's used.
Change-Id: I1e367b3d0816096300a441786619f298134de0a6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
There is a bug in dx.bat in the Google Android SDK tool where
relative paths do not work correctly. We need to use our own
version of this tool until:
https://android-review.googlesource.com/#/c/52680/
..is merged.
Change-Id: I451a3239590919d014a673f3e8e17244e96676ab
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
this is a qt specific option and really should not be hard-coded.
also, the implementation used undocumented api that is internal to the
bootstrapped process, which made it impossible to de-bootstrap it.
Change-Id: If706960671744e64a9a7c366437977a800a6058e
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
... like qt_tool does. otherwise we get linker errors with debug builds
on windows.
Change-Id: I583f277ff3fb75c9fe5f305a6f1b5d066b840c07
Reviewed-by: Debao Zhang <hello@debao.me>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Jonathan Liu <net147@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Used by features in CMake 2.8.11.
This matches the features in FindQt4 in that version of CMake,
namely that the IMPORTED targets contain the appropriate
INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_COMPILE_DEFINITIONS
and that the qtmain.lib static library is automatically linked to
on Windows by executables. Additionally, the
INTERFACE_POSITION_INDEPENDENT_CODE property is set appropriately
if Qt requires users to use position independent code.
Change-Id: Ide341f43fcaf7d722a7bdf1a12b1071c7e548ccc
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
This will likely fix some odd cmake related tests in the CI.
This reverts commit 316d8ececa.
Conflicts:
mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in
src/corelib/Qt5CoreConfigExtras.cmake.in
Change-Id: Ib7714746f96bf12061d92242a42296d200c56c00
Reviewed-by: David Faure (KDE) <faure@kde.org>
The version number parsing needs to handle the reported version string.
Change-Id: Ifd34b2c86b21a1c5e4c91a43447468ca6feab8cf
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Replaced tabs with spaces to align with space-indented code
and removed some trailing whitespace.
Change-Id: I4930afc3df206ef8ee96de3e69f0d69fc4a1c77c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This way find_package(Qt5Svg 5.1.0) will require Qt5Core 5.1.0 or later, for
example.
Additionally, forward the EXACT keyword to find_package dependencies
so that find_package(Qt5Svg 5.1.0 EXACT) will reject Qt5Core 5.2.0, for
example.
Change-Id: I302f5a3a683e6c36ef42f1e81c5f7e6258cf5624
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Alexander Neundorf <neundorf@kde.org>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
otherwise we assume that the user is trying to build a random example
which just happens to live inside a qt module's repository.
Task-number: QTBUG-29756
Change-Id: I17f217b4235fbe04f2c49d1d92ce08b86bb259b9
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
this is cleaner than having it parse qmake project files.
the only remaining built-in version extraction is the fallback to
qglobal.h needed for bootstrapping.
as a "side effect", this fixes the build of modules with mismatched
versions centralized in .qmake.conf, as this was simply not handled so
far.
the -mkspecsdir syncqt option goes away, as there is no use case for it
any more.
Task-number: QTBUG-29838
Change-Id: I6912a38f0e93a26bc267a9e3d738506fd3ad431b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Instead of first finding it and then testing that we can find it.
Change-Id: I1a1090693520b1d6adadef93839f25d277947e76
Reviewed-by: Alexander Neundorf <neundorf@kde.org>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Task-number: QTBUG-28540
Change-Id: I916d104c8aba551ee9a5b34da3fd85dcb26bbf64
Reviewed-by: Alexander Neundorf <neundorf@kde.org>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
project files of bootstrapped modules can, just like those of
bootstrapped tools, benefit from automatic adjustment of QT (and
CONFIG).
Change-Id: I83815e69a2b105caaee0c2e2602828f8eb425eef
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
this affects only webkit when doing module-by-module installation, so it
went unnoticed.
Change-Id: Iab87f4a76fcb0fa9a1b1d6bcab9a73756e416120
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
QT_CONFIG is supposed to contain configure output, not a list of
modules. for example, enumerating modules is not cleanly possible if
modules are mixed with other flags.
the conflation was merely historical, due to webkit and phonon doing
it this way in the preliminary qt4 modularization.
we now have a much cleaner way to query modules (qtHaveModule(<module>),
or less recently, !isEmpty(QT.<module>.name)), which is already used
throughout Qt.
the old way was supposed to be removed for 5.0 already, but it slipped.
better do it now, before people actually start using it.
Change-Id: Iabdf0cdfaab9cd674f634f4c6ece105b2039c850
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
modules which demand it (i.e., qtwebkit) need forwarding pris, etc.,
even when not making a -prefix build.
Change-Id: Id405be8763e94cc074854f799bd785e9cdf62e8e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Andras Becsi <andras.becsi@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
unlike the real compiler, moc does not have these directories built in,
so it would not find headers from a system install of qt.
Task-number: QTBUG-28870
Change-Id: I86f18cdc8953145190163746dae59f4e784f2d78
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Change-Id: I16e05b72e57473239b89498313ba7745ffa6a346
Reviewed-by: Alexander Neundorf <neundorf@kde.org>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
bootstrapping is only necessary if we are cross-compiling or have a
circular build dependency.
Change-Id: I17244457652ca9d4fc797043e57070c2ae3ee5d1
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The 'silent' option to CONFIG will mangle QMAKE_CXX and friends by prepending
an @echo, which sdk.prf doesn't handle (it assumes the variables contain
names of executables, with optional arguments). Instead of teaching sdk.prf
generic command line parsing we ensure that silent.prf does its job at the
very end, when the tools have already had their paths fixed by sdk.prf.
Change-Id: I7093232e5cc37ed8106a3b838f42ad8f1a43fb86
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
For Mac OS X we currently specify build tools without an absolute path,
which means we end up using the ones in /usr/bin. This is wrong, we
should be using the tools from the toolchain of the chosen SDK.
For iOS we do specify an absolute path, by resolving the toolchain
path in the iOS makespecs.
To solve the situation on Mac OS X, we move the logic of resolving the
toolchain path to sdk.prf, and share it between OSX and iOS.
For configure we need to duplicate some of the logic from sdk.prf, as
configure pulls out QMAKE_CC and QMAKE_CXX for running some initial
tests and building qmake. The new macSDKify function also solves
the issue of missing sysroot and deployment version in the flags.
Change-Id: Ib1d239c9904cf3ccee5214b313cf6205869a1462
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
We now take advantage of the fact that xcodebuild -version allows you to
pass the key that you're interested in, to only print that single value.
This technique is used by Apple's own build scripts as well.
Change-Id: I57b8424590d4137a0e7f263a318e17ee2e0dfad4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
so far the assumption was that every qml plugin/module in qt is a
wrapper/extension of a corresponding qt module. this not the case for
the upcoming quickcontrols, for example.
Task-number: QTBUG-28200
Change-Id: If4b8bb6633e76b2a510908d09a010cee12d33634
Reviewed-by: Liang Qi <liang.qi@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
otherwise they would inherit it from qtbase, which may effectively
result in a lie if building against a different release.
for convenience we define the version centrally per repo.
qtbase is special, in that we use the version defined in qglobal.h to
avoid defining it redundantly (the instance in qglobal.h is currently
needed to bootstrap qmake; the configures would need some work to change
this).
Task-number: QTBUG-29838
Change-Id: Ie9a5b0ff0d64b69ff2d34af2f7c42d6278e957cc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The former applies both on Mac OS X and iOS, but 'macx' is specific to
Mac OS X.
ios.conf and macx.conf now share most of their settings in the common
mac.conf. We set the default QMAKE_MAC_SDK before loading mac.conf, so
that any overrides in the device config will apply afterwards. This
means configure's mkspec parsing will be able to read the QMAKE_MAC_SDK.
Change-Id: I0c7e26a6a0103e19b23ef152aa9e4ab461cee632
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Based on the Necessitas project by Bogdan Vatra.
Contributors to the Qt5 project:
BogDan Vatra <bogdan@kde.org>
Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
hjk <hjk121@nokiamail.com>
Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Paul Olav Tvete <paul.tvete@digia.com>
Robin Burchell <robin+qt@viroteck.net>
Samuel Rødal <samuel.rodal@digia.com>
Yoann Lopes <yoann.lopes@digia.com>
The full history of the Qt5 port can be found in refs/old-heads/android,
SHA-1 249ca9ca2c7d876b91b31df9434dde47f9065d0d
Change-Id: Iff1a7b2dbb707c986f2639e65e39ed8f22430120
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Instead of hard-coding the SDK and deployment target.
A host build will already use the host-makespec, so now that we
always build against an SDK, these mkspecs will have the SDK and
deployment target set.
Change-Id: I2b0343ae75f7de12081bab8346307b96b3883f62
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is enabled only for -developer-builds and only for certain
compiler-version combinations that are in a whitelist.
It also requires each library, plugin or tool to declare whether it is
supposedly clean of warnings. When most targets are clean, we can
consider inverting.
Change-Id: I17b5c4e45aee5078f9788e846a45d619c144095a
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
We don't want to hit the network, as a flakey network or slow server will
hang the XML parsing. We assume the XML is well formed.
Change-Id: Idc4898a925a46222954bf633a04ea9fe148c6797
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This file is now included by three types of Qt output: modules,
plugins (including QML plugins) and tools.
Change-Id: I5085f6ff37f70e9228303bf0520040adc2e2d7a5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
configure.prf checks if MAKEFILE_GENERATOR is set
to something it can work with. ios/default_pre.prf
unsets MAKEFILE_GENERATOR.
This breaks QtMultimedia at least. Add special case
for iOS to configure.prf and set QMAKE_MAKE to "make".
Change-Id: Ie8feaeefe4a932d735a0cd4c09e869ca1341aae5
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
In case they provide their own main that calls UIApplicationMain.
Change-Id: Ia050277ae5cbcbf01bc57b87ec37a74db9568059
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Ideally we'd only have to do QTPLUGIN += ios, but this doesn't work as
we need to link with the force_load linker option. Even trying to build
on QTPLUGIN and then replace the -l line with what we need will fail, as
the prl logic in qmake which runs after all the prf files does not know
about the force_load option and will then fail to resolve dependencies
from the prl file.
Since we load the platform plugin using -force_load, there's no need to
generate a cpp file that does the plugin import.
The main wrapper is not a real Qt plugin, and doesn't have an import
function that we can call, so we link it manually instead of relying
on QTPLUGIN.
Change-Id: I0381a3c9ed7f8d41a4121e1fc0b7c0e210a8b832
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
As long as Qt Creator does not provide any iOS integration, and the
app bundle we create using the Makefile generator is not good enough
to deploy to a device anyways, producing Xcode projects make the most
sense.
We base the decicion on whether or not the project depends
on QtGui and has app_bundles enabled. This prevents configure
tests and other tools from having Xcode projects, but allows
examples and demos to build out of the box.
Instead of setting the generator unconditionally we unset it in
default_pre so that we can detect if the user set it manually. This
means the user won't be able to inspect the MAKEFILE_GENERATOR variable
from the pro file, but this is less of a use-case then overriding the
generator from the command line or prooject file.
Change-Id: I881cf3e29631445f83ea4ff0979f7a566e4810f5
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
And use configure's -sdk argument to choose between the iphoneos and the
iphonesimulator SDK. xcodebuild -showsdks can be used to list the
available SDKs. Passing an SDK without a version postfix implies
the latest version of the SDK.
Change-Id: I881df754d522fc91aaa16ba3e39cf0c37a21a1f1
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Currently the Qt5_MODULE_TEST_DEPENDS variable is maintained individually
in each repo. This patch makes that obsolete.
Change-Id: I1a72bb4da70b9ace6f79296d6a3fb295eaa999ff
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
These will be used by ctest_testcase.prf.
Change-Id: I8a0e6e1eb110daba41b007c8309f3cb9a2059ecb
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Introduce QT_OPENGL_ES_2_ANGLE_STATIC define for static builds
and modify export accordingly. Provided static instances
of gl::Current and egl::Current for Qt's single threaded
use.
Task-number: QTBUG-28196
Change-Id: Ia75699d6da103fb8dd9d5fe97c1ee51e48a74406
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Allows us to dynamically generate the command line option for iOS later,
and allows the user to override QMAKE_MACOSX_DEPLOYMENT_TARGET with the
expected effect on the command line options.
We unset PERL5LIB to ensure we get the system Perl libraries, since the
Mac OS 10.6 CI machine seems to have a broken XML::Parser::Expat from
macports/CPAN.
Change-Id: I04430c7b1daf9452d72f9a04a6b7f8d0d6926884
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This way, the Release library is chosen if Qt is configured to
build both debug and release, and if the consumer configuration
is not an exact match for 'Debug'.
This means that RelWithDebInfo and MinSizeRel, which are 'standard'
configurations in CMake with mulit-configuration generators, will use
the Release version of Qt. All other configurations will also use the
Release version, unless MAP_IMPORTED_CONFIG_<CONFIG> is used as
described in:
http://doc-snapshot.qt-project.org/5.0/qtdoc/cmake-manual.html
and in the cmake documentation:
http://www.cmake.org/cmake/help/v2.8.10/cmake.html#prop_tgt:MAP_IMPORTED_CONFIG_CONFIG
Task-number: QTBUG-29186
Change-Id: Ifc11a9e19fcb304297c204e34a3b25c510329767
Reviewed-by: Brad King <brad.king@kitware.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
This ensures that invoking the macro from a different module (operating
on a different target) is not possible.
Change-Id: Idbcd41d03172a8f1dcea26954464ab981fce8879
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Since we're only including the Extras file one time, invoking set() for
the include dirs again will overwrite the addition of include dirs in
the extras file.
We only need to populate these variables if not set anyway, so do that.
Change-Id: I04dad0674778e79c8c12c18231b8ce6c92edf881
Reviewed-by: Alexander Neundorf <neundorf@kde.org>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
this function is called only from library TEMPLATEs, and always with
exactly one word as the only argument.
Change-Id: I6282e3826791f89e6cf89dde625c8166e4e56028
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
these have no (useful) install target, so it makes no sense to reduce
the "build" to installing sources. suppressing the actual build can be
achieved with -nomake examples instead.
conversely, as the build dir is the install dir, people actually need to
be able to (selectively) build examples in there.
Task-number: QTBUG-29756
Change-Id: I98f34235442b552e51c0d5f5cec96a3eab4f1e7f
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Instead of setting -isysroot in both arch.test, compile.test, the various
mkspecs, and sdk.prf, we now propgate the chosen SDK as the qmake
variable QMAKE_MAC_SDK, which is then handled exclusivly in sdk.prf.
The QMAKE_MAC_SDK variable, and -sdk argument to configure, is expected
to be of the short-form name, eg macosx or iphoneos, not a full path, as
that's what Xcode also expects. We take care of translating that into
a full path for -isysroot/-syslibroot in sdk.prf, using xcodebuild as
a helper.
Change-Id: I281655b2fa5180c6e78ffdce36824e4a91447570
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
... instead of as a fallback in default_post.
it was this way in qt4, and it requires less code to be written in the
end. we are already doing it for debug/release as well.
Change-Id: I6e02849d61d14a18375cf64a5990768931ebac48
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
all tests that happen after default_post loads resolve_config can rely
on debug vs. release, static vs. shared, and staticlib vs. dll being
properly "de-conflicted".
Change-Id: Ie0b4defcd6024bd1c25f53ba7e03621052d96492
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
the current approach of having "free-flying" prf files for such a core
issue is rather insane. this was noticed early on, as evidenced by the
forcible loading of debug/release/debug_and_release in default_post.
however, things remained a mess, in particular static vs. shared.
consequently, the commit merges all related feature files. the actual
config resolution is put in a separate feature file, so it can be loaded
by resolve_target if that happens to be loaded early on.
Change-Id: Ie30e7c63cabe9409a3263ca1650e323a870926f2
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
it differed from QMAKE_LIBS_OPENGL only for the irix/sco/unixware -cc
specs for not entirely obvious reasons. as all these specs are obsolete,
remove it.
Change-Id: I7d50ffa11ff830371ea52c9ebe25e1f1bc56b307
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
there is mightily little point in unsetting variables right before
unconditionally assigning to them.
Change-Id: I24c1814ce38bf9aab4496679b1a670f3cd55c536
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
If Qt is configured with -libdir /some/dir/outside/the/install/prefix/,
then for use absolute paths for the executables and include dirs too.
Change-Id: I5ccf62be6f93f97d934df62038fe4cd40dca9a93
Reviewed-by: Alexander Neundorf <neundorf@kde.org>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
all non-installed tools are properly registered, so they don't need the
fallback. conversely, we can assume that non-registered tools are
already installed.
this enables us to build docs in qtbase after an incremental
build+install up to qttools.
Change-Id: I95a55f6b84e01885bcf6dd656caf0dd2b679bb73
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
This is the <prefix>/include directory which is independent of the
module and which only has to be used once. As everything uses QtCore,
it is enough to set it only there.
The CI system is a special case, in that it tests things before
installation. Handle that case too.
Change-Id: Idcdf9617e199b7d490cb3553cce07f1f464b3bec
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
As the Extras file can do things like append to a property (as in
QtCore for include directories), that is something that should be
done only once when the QtCore target is first defined.
Change-Id: I5163912bccfda1ff43a02eb01f67ac59e6f6b24b
Reviewed-by: Alexander Neundorf <neundorf@kde.org>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
the pkg-config file names follow the TARGET by default. as we create
frameworks without the major version infix, all references to Qt5* would
be invalid.
Task-number: QTBUG-29453
Change-Id: I82e7de017a8f17f7d2d7b4a2a61a180125ca29a0
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
it's not used for anything other than display, so we can put a space
there.
Change-Id: I77e156856efeaaa964ff3bf2369bcd5586bac7c6
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
there is no point in duplicating the information in every module.
host_bins is exported only here as well.
Change-Id: I2f816e1cade9761a2c0d97c7ca1c90293095bfb1
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
users need access to the Qt configuration, not some internals of
module's build system.
Change-Id: Ife3f668282969d444282d57152c11ed0f741076f
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
-rpath does *not* imply -rpath-link when x-building:
ld(1): "Searching -rpath in this way is only supported by native linkers
and cross linkers which have been configured with the --with-sysroot
option."
it doesn't hurt to have the "excess" -rpath-link for native builds, so
just remove the cleanup.
Change-Id: Ic39c1f4d6c2e3770d43a5ed3e56cf89a146edf85
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
if the libraries are in a non-standard location, but no rpath is used,
rpath-link is needed. this is often the case for non-prefix builds
(which have no forwarding pris any more).
as we cannot store absolute paths in the final pris, we need to store the
module names, and resolve them only at use time.
Change-Id: I1538b5d531611c76a2d7058a3b2ff683bdcbe427
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
as everything is built inside the common build/install dir, there is
no point in the fwd pri stuff.
as a "side effect", this makes it more straight-forward to relocate
non-prefix builds, which is the default on windows.
Task-number: QTBUG-28827
Change-Id: I010246a9ad87cf74974dc168768b1a8625f73260
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
move the regular pri file creation into the "sub-prf" and rename it
accordingly. the original reason for the split was the deep magic in
activeqt (and phonon), which is gone now.
Change-Id: If40e941afc9293725630ed6bcf3e4ef18a692f66
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
-developer-build enables an actual build of examples, based on the
assumption that developers want to test it (it can be still disabled
with -nomake examples). regular users otoh want only the examples
sources installed.
Change-Id: Ifc6a108099929175a3960480802b271a758fdd38
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
we need to collect the sources of the install targets for the check that
all files have been properly handled, but of course we must not add these
files to the source install target, as that would mean double installation.
Change-Id: I6acb56f2a993b6ed81d1031d5dc0a0da30a53b54
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Curiously, qmake could fix .prl and .pc files for unix, but only .pc
files for MinGW. qt_module.prf seems to have known this.
Task-number: QTBUG-28902
Change-Id: Ice9983a69813690c0d4b96ca11589440182569a0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Fully modular prefix build now puts the includes and libs into each
module's own builddir, so the else branch was simply bogus. Replaced
the else branch with the real base for modular builds. This allows
the paths to be successfully replaced when installing metafiles.
Change-Id: I056a923288965b560a4e9b0ba7add1aac912199f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
otherwise qmake will just take TARGET and lowercase and capitalize it,
which not only looks weird, but also does not match the Requires: fields
we generate.
Change-Id: I4a070ff256fffd2b780acb0361d4213d0032dbb9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Dihan Wickremasuriya <nayomal@gmail.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
This is a less error-prone way to calculate relative paths.
Task-number: QTBUG-29110
Change-Id: If4509ef278e48dcf08bdcc904d21534b4c05993f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Cross bulding on unix for mingw exploits the fact that makefiles
generated for mingw work with plain make. There is no mingw32-make, so
this is the only option.
Arguably, plain make could also be used in an MSYS environment,
perhaps detected by MINGW_IN_SHELL, but there might be good reasons I
don't know about not to do this.
Change-Id: I694c74046a307c2887af1c30cca36f95e242adc1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
this is much more elegant than the so far propagated !isEmpty(QT.foo.name).
also replace feature-specific tests (no-gui and no-widgets) and the
obsolete contains(QT_CONFIG, foo) syntax.
Change-Id: Ia4b3c8febcabf9eeca67b1f9173a523820b1038b
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
Reviewed-by: Tasuku Suzuki <stasuku@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Fix MinGW build errors by using the standard main signature.
Change-Id: I0ebe7307a825a7ec50e654f163fbf8fe7060a478
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Generalize the check for gui by checking for needs_qpa_plugin
CONFIG value instead, which gui adds to MODULE_CONFIG.
Task-number: QTBUG-28215
Change-Id: I5834a3f81e5c3868ee1a3fa405ebc6410db1f900
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Using some modules requires importing static plugins also for shared
libraries (namely QtAxServer), so provided a way to force plugin
imports even for non-applications using force_import_plugins
MODULE_CONFIG value. This required moving the plugin handling after
qtAddModules calls in qt.prf.
Task-number: QTBUG-28215
Change-Id: Id6bb92ed7c078cc8c54538ddc9bb8e8ad316f277
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The location of the mkspecs directory comes from the archdatadir, which
distros will all set.
Change-Id: I20dbdce76db13dbd37eec065009e215f98985907
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qt is already added by spec_pre.prf, warn_on and depend_includepath by
default_pre.prf.
Change-Id: Ic00e0ba496d698ed9659c476f2ca99fc0f86a093
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
When building Qt static, plugins get module .pri file, but those files
do not get installed in Windows. This is because both .pri generation
and install target statements are scoped with !build_pass, which means
Makefile.Debug and Makefile.Release do not get install_pritarget
target.
Fixed by doing only the .pri generation in !build_pass scope.
Task-number: QTBUG-28606
Change-Id: If3f49b578af1d9171a8bce67793ecb3f902a6da8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
it's the very antithesis of modularization to do it.
Task-number: QTBUG-27722
Change-Id: I2540e1a70e67b55420246d0c209314c05c65a85f
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The variables these files refer to are not set anywhere anymore.
The Unix thread.prf file is still needed, as it is still effective and
is activated by qt.prf.
Task-number: QTBUG-25106
Change-Id: Ia514192d28785205df3710d78ee597285d4136b0
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
rpath is meaningless for static libraries.
and windows has no concept of rpaths to start with.
Change-Id: Ia02bbdfbf7112e7082175c3051c0839ac0900f57
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Since all gui applications already need some QPA plugin added,
we might as well add the default plugin and generate the code
to import the plugins automatically.
User can opt out from the automation by removing relevant
items from CONFIG variable: link_qpa_plugin or import_plugins.
Task-number: QTBUG-28131
Change-Id: Ic171c363464c099143374d3e39bcc28f6edf73d2
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
generally, don't install anything from the top-level examples dirs
automatically. the global README and the aggregator examples.pro are
installed explicitly.
Change-Id: I5f6b8760f37d917b800fa85979896a471778cac0
Reviewed-by: hjk <qthjk@ovi.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
