the code makes no sense, and was added with the QNX port without comment.
there is already a detection a few lines up.
Change-Id: I18ec18604c37c7c42f2649a658dd22324d481dd3
Reviewed-by: Andreas Holzammer <andreas.holzammer@kdab.com>
Reviewed-by: Harald Fernengel <harald.fernengel@nokia.com>
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
this overrides the magic that makes examples only install their sources
in production builds.
packagers may want to force the build of the examples, so they can
package them up for demo purposes.
this is actually why we formerly had the split between demos and
examples ...
Task-number: QTBUG-30788
Change-Id: I5633f69404c5aa6846f5496e8f161a273a7a7da3
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This is the easy fix: looking at what is supported by the NDK. If people
have weird setups, then they have to specify -android-ndk-host. We do
actually detect the host architecture later, but using that would be
a much bigger (and riskier) change.
Task-number: QTBUG-31275
Change-Id: I18db878031baa2e1ee2fa4beff364d58d8bd3c7a
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
It's not needed, and when $outpath/lib doesn't already exist
(when shadow-building for example), $outpath/lib ends up being
a copy of libgnustl_shared.so, when it really must be a folder.
Change-Id: Iaf3af6f4183090137043549cb8d9899c2bc92f24
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
xcrun occasionally prompts for a license or outputs errors which
results in:
configure: line 2488: [: : integer expression expected
Check the output and bail out on error.
Change-Id: Ic1ae62b5f19cf87365c38901e98d6b385cdb39a4
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
instead, rename it to syncqt.pl and rely on qtPrepareTool()'s new
ability to correctly invoke it as a perl script even under windows.
the wrappers themselves have been trivial at this point, so there is no
added value in keeping them, either.
Change-Id: I77cf65edbcfaa48ed1900defe940d4eb4b82d5b9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
... and introduce -hostlibdir configure option for symmetry.
the libraries built for the host have no business in the target prefix.
in principle this code would even support dynamically linked host
libraries, but that's currently unused.
Task-number: QTBUG-30591
Change-Id: I8e600fa4911a020fb0e87fbf7ef2f35647c7c4d5
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Ivan Romanov <drizt@land.ru>
MSYS bash (and other msys-compiled executables) perform path
transformation much like Cygwin. This causes syncqt path
substitution to not work correctly, so use 'pwd -W' to get
the Windows version (though with forward slashes) of both
relpath and outpath.
Change-Id: I808e3ef9206ed5f5bd8b6879d12afe664e589e0c
Reviewed-by: Alvaro Burnett <alvaroburnett@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
... instead of scoping the defines in qconfig.h, which relied on the
Q_PROCESSOR_xxx defines and meant that we had to include qconfig.h
after qprocessordetection.h, which added a whole bunch of other
dependency issues.
We now let configure write QT_COMPILER_SUPPORTS_xxx to qconfig.h as
before, without any scoping, and then undefine the ones that don't
apply for the given processor. This means we need to include
qprocessordetection.h before qcompilerdetection.h in qglobal.h,
but the former does not depend on the latter, so this should be
fine.
Change-Id: If00c00d405463e9626fa0f7f5e6b17f68778904f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
It makes more sense to keep this workaround header together with the other
libxkbcommon files for a better access point since it's used by several *.pro
files.
Change-Id: I63d4eb58f6e7f3852834e41c4b6e058a2c962233
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
1) -qt-xcb
a) Use xkb from the 3rd party libs. As it is done for the other xcb
dependencies when qt configure with -qt-xcb.
2) -system-xcb (default)
a) If xkb found then use xkb from the system. (Currenly xkb is not
enabled by default when configuring libxcb library).
b) If xkb can't be found on the system then keyboard state will be
updated from X11 core events.
Change-Id: I7c3dbce6daa2cec52067cd5af80f19040233a0db
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
This library is required by the XCB platform plugin. As we depend on
very recent version of this library and it might not be available
in base repositories of distributions, users can use -qt-xkbcommom
switch to build Qt with the bundled version.
Change-Id: I0ed2a5cc2f1df98b0e7cc926cabfa69818674e08
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
The configure script does not actually produce a "confclean" make target.
Task-number: QTBUG-27735
Change-Id: Ia0f9e33e50c35cc6bb2941853e518a40fc9edaee
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The warning is more likely to be seen if it's closer to the end of the
output.
Also report whether we found xkbcommon in the main output. Note that
xkbcommon is used by Wayland too, so it's not dependent on QPA or on
the XCB backend.
Change-Id: I143327eea4e17fa06bc7c24c677ae0bd00e65711
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Keep options sorted and use indentation to group together related
options (QPA backends, image formats and SQL drivers).
Change-Id: I97d330a13a4daa4567ff741dc26e11f458ae7f53
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Neither /dev/null nor NUL work with Qt on Windows. For now, use
an empty file for the cases where qmake is used with /dev/null.
I filed a bug for this:
https://bugreports.qt-project.org/browse/QTBUG-30562
Change-Id: If5351214ae5a0ebe50ae46b155c327ca0dc59f98
Reviewed-by: Alvaro Burnett <alvaroburnett@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
A gap after option name is needed to select it with double-click.
Also I added padding periods for -testcocoon because it has no them before.
Task-number: QTBUG-30589
Change-Id: Ib5b970f9b17cad43609fbc53dd05a995aaf29b45
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
For now there's only one architecture per host/target, but
this will change once we start detecting the CPU features
for both device and simulator on iOS.
For convenience we set QT_CPU_FEATURES to the resolved
value of the current architecture, so that simd.prf still
can use QT_CPU_FEATURES directly.
Change-Id: I28e8b339a5c30a630e276165254dba09a3da6940
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
So that the user doesn't have to pass -no-pkg-config and -nomake, when
we already know that those flags are needed and that the build will break
without them.
Change-Id: Ic07e02bc1800f177cf09f704104c1a76bfc50aa2
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
QT_CPU_FEATURES is internal and only used by simd.prf, which is
also internal. This matches the available CPU features which are
detected using config tests and written to CONFIG in qmodule.pri.
Change-Id: I8eb35448e2954a54c228d3617f29afc0283a7db5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
We don't need it. Let linux-g++ be the default on all Linux builds,
period.
Task-number: QTBUG-30590
Change-Id: I26c73bf4f054684763b64ef5651b3488363ea7a1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The default lib and include dirs are resolved using the target
compiler and with a sysroot, so they are not relevant for host
builds.
Change-Id: Iceb2eb865d0732b9a6f5896ad126200ae8e8a04e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
We now have host_build to distinguish the two, and we load
qconfig.pri from both the host and the target mkspec, with
host_build set correctly.
Change-Id: I8b8b80d5487d10bb1d4585d27d10300f609a7775
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
We depend on Xcode for building Qt itself and user application on Mac OS.
The user may have an Xcode install that is not set up properly, in which
case we would fail compilation in mysterious ways. Instead we try to
detect misconfigured or missing Xcode installs as early as possible.
We try to detect if an Xcode install has not been chosen yet, and
if the user has not accepted the Xcode license agreement. We need to
do these checks both in configure, as early as possible, and in mkspecs
on Mac OS, as we need to error out if the user tries to build an app
with the Qt SDK, but with a broken Xcode install.
Change-Id: I4e3a11077a61dc5d4ee2c686d01044a9bb2c1c79
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.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>
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>
We used to disable NEON completely, as the iOS toolchain does not
handle the GAS syntax of the pixman draw-helpers. But we can limit
the disabling to just the draw-helpers, which means we get NEON
optimization of eg. QImage and QString.
Change-Id: If350b06ce521cca8b24468be5a168ff21e9e7124
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
We're trying to parse GCC output, so let's make sure that they are in
English. I've seen some reports that "search starts here" was
translated to some locales.
Change-Id: If09b1f45607f65d054496db65418e413b8aa8d48
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
the de-duplication has the side effect of sorting, which is a very bad
idea: x-compilers tend to append the host library paths at the end, and
we really want them to stay at the end.
and the lists should have no duplicates to start with. should we find a
compiler which breaks this assumption, we can use qmake's $$unique()
strategically.
Change-Id: I01560e3c33736c2dfffdb05d5c960c492439c946
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
evdev support in eglfs is now guarded by QT_NO_EVDEV, so this
check is no longer required. This allows eglfs + tslib to be
a supported combination.
This reverts commit a95e396a83.
Change-Id: Icf7c15121b7eca1131d412b05b956cd5d7f189ae
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
the dlls being in lib/ is kind of an accident (a side effect of how
qmake builds them). in fact, the libdir should be entirely irrelevant
for windows deployments (and indeed, the SDK is delivered with dlls only
in bin/).
Change-Id: If47e72b24774721a61ba63847f6132f88ff110be
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
Otherwise, we end up with an empty QT_LFLAGS_SQLITE and the plugin
won't link.
Change-Id: I026f60bf9cd075218dbe2888fbb7fc82782b27ca
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
I don't need that warning on my Mac.
Change-Id: I18c06135ba88a037103fdda0982976f4a87c553e
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
Reviewed-by: Gatis Paeglis <gatis.paeglis@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Since c45595d648, we use the toolchain
based on the XCode SDK, not the one in $PATH. Turns out that the Clang
that comes bundled with XCode 4.6 reports its version as
Apple LLVM version 4.2 (clang-425.0.27) (based on LLVM 3.2svn)
Instead of "Apple clang". So we need to match for (clang|LLVM).
Extended regular expressions (with -E) were necessary because the sed
that comes with Mac OS X is apparently broken and will not work with
\(clang\|LLVM\). GNU sed accepts -E as an alias for -r, meaning
extended regexps.
Change-Id: I5a15de30721216b086c3d39a080cc6496c503985
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
There is no logic in configure to detect compiler capabilities
in the host- and cross-compilers separately, so if the
cross-compiler has more capabilities than the host compiler, the
compilation will break. This was the case for c++11 on Mac, which
is supported by the Android cross-compiler but not by default on
the host. There is a fix planned to enable c++11 on Mac, so
this is a temporary patch to work around the problem by disabling
c++11 explicitly until it has been fixed.
Change-Id: I2048dc7f63991c97b11b3980ac91292d2c9b7ce4
Reviewed-by: Morten Johan Sørvig <morten.sorvig@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>
It is needed for implementing the shortcut functionality in the xcb platform
plugin and for the compose key input context plugin.
As announced on the wayland-devel mailing list - the libxkbcommon 0.2.0 is
the first grown-up release of the library (Tue Oct 23, 2012). [1]
[1] http://lists.freedesktop.org/archives/wayland-devel/2012-October/005976.html
Change-Id: Id5d45e1a5afe49cf9ec5312318bd173f5a067f62
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
it's weird that the output from the two variants is differing, and that
after building qmake it appears to hang.
Change-Id: I2ac3ace11e958effe787b13e1300eb1d2839ae98
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
7de9d3709 broke them, because suddenly every -l* switch was parsed as a
library. fix this by re-arranging how the options are parsed.
this obsoletes d7ab351cdd as well, by being more generic.
fwiw, this syntax is stupid to start with, because all unknown -l*
options are implicitly libraries and create confusing configure
failures. emulating the compiler/linker command lines isn't such a great
idea ...
Task-number: QTBUG-29174
Change-Id: I11bac7a6f458664dff8cbe57ed9cd33a08d5e9ec
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
note that the value is written verbatim to the qmake file, so additional
quoting may be required on the command line.
Task-number: QTBUG-30102
Change-Id: I02ca9a44fae82b6932982e6385508b8a304cc1e7
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Since we use the Clang from Xcode's toolchain now, the OS version is
not relevant.
In practice this means we will use clang for Xcode 4.2 and up, which
means it's possible to use clang also on Mac OS 10.6 (Snow Leopard),
where Xcode 4.3 is not available.
Change-Id: I9817e237cdd82d10b93aaaa3c90e35767cdca751
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.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>
Is needed now that we write QMAKE_MAC_SDK with a !host_build scope
in qdevice.pri.
Change-Id: I298cc660b496460190337c175aef684a5522d5cb
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
qdevice.pri is not target/host specific yet, so we were loading
it and overriding QMAKE_MAC_SDK to iphonesimulator eg., even
for host tools such as moc.
Change-Id: I10277e60e1da84dda239e32a6f19b40dc48f084a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Version 3.1, shipped with Xcode 4.3, has the same issues compiling Qt's
AVX code.
Change-Id: Icb778fbd9d61f01aa84365661af050c9442d4d7f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.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>
If the command is quoted, it can contain anything but quotes (we do not
support escaped quotes, so single quotes have to be used). If the
command is unquoted we look for the first closing parenthesis. We used
to do this using .*?, but the greedy modifier '?' didn't seem to work,
so we now use an inverse character set.
Change-Id: I40660ce7aef6a6b6d480292d28da1b079bb161da
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Instead of setting it explicitly to 10.6. Before 736e4258a this was
not a problem, as we were hard-coding the version flags as part of
the C/CXX_FLAGS for each makespec, so getQMakeConf would pick
them up automatically. When 736e4258a introduced sdk.prf as the
place to resolve these flags in a single place, it broke the
qmake build for macx-clang-libc++, as we were then falling
back to the 10.6 target hard-coded in configure.
We fix this by duplicating some of the logic from sdk.prf, by
pulling out the QMAKE_MACOSX_DEPLOYMENT_TARGET variable
and adding to the C/CXX_FLAGS.
Change-Id: I04afc7525031727c2504588c70dd3f7892cc8e42
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>
Should be applied to Qt modules. Not interesting for third party
users.
Change-Id: I8fce821af397e3ace011a426c762319f6d30004f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
The dbus_watch_get_fd function was deprecated in D-Bus 1.2 (technically,
in 1.1.1, but that was a development release) because it had a bad name.
Sockets on Windows have file descriptors, but they are not shared from
the same pool as the CRT library's file descriptors.
This commit raises the minimum required version of D-Bus to 1.2. This is
the first requirement raise since this code was introduced in 2006. For
some reason, the D-Bus 1.2.0 release seems to be missing, but 1.2.1 was
released on 04-Apr-2008. That's ancient enough for all distributions
Qt 5 is supposed to run on.
Change-Id: Ia6bbc137fffbb27c77290ed3e32d3380f0ae3c54
Reviewed-by: Lorn Potter <lorn.potter@jollamobile.com>
The LLVM version in Xcode 4.5 and below does not handle the GNU
assembler syntax in the pixman assembly file.
A possible alternative workaround is to include a preprocessed assembly
file using https://github.com/hollylee/gas-preprocessor.
Change-Id: Id95add669c60d3a7da823e5975afdd1f88f71977
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Clarify in the configure --help documentation that the text between
parentheses in the -make option indicates the default parts, not all
the parts that can be chosen from.
Task-number: QTBUG-28826
Change-Id: Iac9cf294b8054823ecfaf262aeafab7779ce4c8b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Must use ; as the path delimiter instead of :
Change-Id: I549e1652ef5bbae09c8fddec3e83ac9f52cec3a4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
this makes it possible to exclude modules from the build without moving
their sources out of the way. substitutes the much-requested -no-webkit.
not adding a symmetrical option, as it is relatively pointless:
to build only specific "leaf" modules, you only need to run
"make module-qt<module> ..." once you configured. and removing
particular "intermediate" modules is achieved with this very option.
Task-number: QTBUG-26697
Change-Id: I25cebdbd029885a2c653c4cde696f9bb78691768
Reviewed-by: Tuukka Turunen <tuukka.turunen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Replace the old sed / template @FOO@ method with echo.
Enable MSYS bash to build qmake.exe
Use qmake/Makefile.unix for all win32-g++ builds.
Change-Id: I6e27d69b28d27131838bbbb3a4ee5a08b470f31b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@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>
So that mkspecs and features may rely on the host_build test.
Change-Id: I18fee4820d9e2904285afcc7ddb8f1cc3d025fef
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.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>
The chosen makespec may spit out errors for various reasons, which will
influence steps such as detecting pkg-config or the architecture test.
It's preferable to catch any issues with the makespec as early as
possible and exit configure before the errors propagate to tests.
Change-Id: Iecbf3217c36dea9f5e0677c58171b72cb6ce1e0b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Passing -sdk to configure should affect the target build, not host tools.
We skip passing MAC_SDK_FLAG for the host arch test as well, since as for
qmake the SDK should only apply to the target.
Change-Id: I3902355715234b9300a65d3095b9c925d9492311
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
The exact same hunk is present 100 lines below.
Change-Id: Ia3d61037b29186368e30f95f4162282d38bca972
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This allows for example the iOS mkspecs to use xcode-select to get the
path to Xcode's /Developer directory, which is then in turn used to
set up QMAKE_CXX (which is needed by configure).
Coprocess is GNU awk specific, so we're just using getline.
http://www.gnu.org/software/gawk/manual/html_node/Getline_002fPipe.html#Getline_002fPipe
Change-Id: I7e88112bea68f039361d6e96ee581eedf129ab02
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Change the default libexec directory to 'lib' on Windows for default
configurations. This makes sure that e.g. qtwebprocess can actually
find & load the right Qt libs.
A separate libexec directory was introduced to avoid conflicts between
a system-wide Qt in PATH and a custom Qt installation. However, since
there are no system wide Qt installations on Windows this isn't an
issue, but getting the executables to find its Qt libraries is.
Alternatively we could have also placed it in the 'bin' directory.
However, putting it in the 'lib' folder carries the notion that,
unlike the binaries in the bin, the libexec executables might have
to be deployed with a target application.
The exception is when a separate archdata prefix is specified, and
$$archdata/lib won't contain Qt libraries. In this case we use libexec
like on the other platforms too.
ChangeLog: [Qt for Windows] Fixed launching of QtWebProcess.exe by
changing default libexec directory to 'lib'.
Task-number: QTBUG-29661
Change-Id: Icbb15fb98474d6fef8ac9310f2e2b482d3282f79
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
On Windows, it's completely different and we don't currently support that
compiler anyway.
Change-Id: Ie3365ea103c93c63e79ebb1d4908c361173ac449
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The current code matches *g++*, which matches "clang++" and detects
Clang as GCC. That's highly incorrect.
Change-Id: Ifd85bbd35aa130be3094fc75d471614d06ca23bd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Keeping accessibility and only disabling the bridge will
enable more builds to work.
Warning about disabling accessibility disabled is needed
because in QStyle it is used to discover semantics about widgets
(if a toolbutton is in a toolbar).
Change-Id: Iae4e6ab63479743bdd70cba4b1954ec7cf3f88e9
Reviewed-by: Jan Arve Sæther <jan-arve.saether@digia.com>
