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>
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>
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>
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>
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'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>
