... as that causes debug+release installs to overwrite each other's
postprocessed files.
introduces CONFIG+=sliced_bundle, which instructs qmake to create
file-by-file install commands. we don't know whether people are not
putting files outside qmake's knowledge into the bundle build dir, so
this mode is not necessarily backwards-compatible, and thus off by
default.
Task-number: QTBUG-28336
Change-Id: I23e90985ccd3311f0237ed61aadca6d7ed8325b7
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Some packagers don't want to install the private headers.
Check the existence of private headers only if the 'Private' component
is specified when finding the package.
Task-number: QTBUG-32466
Change-Id: I1fdbfb25e8ce485cd051564b937f766b2733741a
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Use "_" instead of "-" in variables so variable replacement works
properly.
Change-Id: I2b17dca8f2351bc0933c165017f3fbb9393b0514
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
For developer builds, there is no need to run the test a second time.
Change-Id: I3564874cb2e9d6cc243e25a89ecd7f89df23b0bd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Should not be needed anymore (as of 3d0a60aaa4), as we now use libc++
automatically when C++11 support is enabled.
The specs were deprecated in Qt 5.1 (commit f7a7859a7).
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: I6653f191b99f7c51c3f02a62c6ef68591b2dfa70
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This gives us better consistency across the Qt ecosystem.
Change-Id: Ie12ebb6e8c826ed2e0445eb37de0b79595da41c2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The test should still be run, even though it is insignificant.
Change-Id: I6a3853e2b0e9670152b4f329dbceed2986a7e008
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
the forward-referenced directories don't exist yet, so we get pointless
warnings. in fact, this is why we do a multi-pass build in the first
place, and consequently using indexes during the first pass is
illogical.
Task-number: QTBUG-32152
Change-Id: I66bf6b43238827e87cb8bf6932d581b808c1032d
Reviewed-by: Martin Smith <martin.smith@digia.com>
the previous attempt broke ActiveQt, as it actually has public modules
without headers (they are provided by a common base module).
so explicitly mark the internal modules as such instead of applying
heuristics.
Change-Id: I8d8a2ee66f02c3444da2036a497e7f382f089f62
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Google moved dx.bat into a new build-tools/VERSION folder
meaning our dx.bat no longer found dx.jar. Fix this by
passing into our dx.bat, the location of the real dx.bat
Removed hardcoded 17.0.0 and %ANDROID_BUILD_TOOLS_REVISION%
path searches.
Change-Id: I91c12c01745d6f12edbd126102b8f06eba291402
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
Add mkspec win32-msvc2013 and make VS 2013 known to configure and
qmake.
Change-Id: I6e63a4d679727a8a3f068f377956185996d72bce
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
This reverts commit 1ef74a763a, as
assembler files in SOURCES break compiling with -pch, as we don't create
a respective PCH.
instead, compile assembler code with QMAKE_CC, not QMAKE_CXX.
the reason why this change is needed in the first place is not clear to
me, but i guess that CXX defines some c++-related macros when
preprocessing the file, which breaks further down the line. this is
counter-intuitive, as the g++ frontend should treat the same sources the
same way as the gcc frontend (differences should be limited the the ld
invocation).
Task-number: QTBUG-29765
Change-Id: Ic0116b3a5fa621f12ac41cadf3062ff00b538e85
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
if a private module was used without the suffix, it would not add any
include paths, but the library would be still added. as long as the
includes were written as <Module/private/Header>, this would not become
visible, as the public modules would add the common include path ...
however, this soon won't be the case for mac frameworks any more. this
change makes the problem visible early on.
Change-Id: I8b1a20313ad736cb49507f07fa623e9aa812f651
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The Qt CI system runs the unit tests after installation, but
with the qmake in the build directory. This means that the
installed content is not unit tested. Add an additional cmake
unit test to test the files in the install location.
The new test is marked insignificant for now until the true
effect on the CI system is known.
Task-number: QTBUG-27315
Change-Id: If9f12e88cfc741946cfabc25dbf789a11a2af4b8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The 'BUNDLEIDENTIFIER' key ensures that we generate an rfc1034
compatible identifier.
Change-Id: Ic5cefb8ae888d768dd793813e7ee3c23c9a5582a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
We haven't fully agreed on whether headers should be in $includedir or
not for builds with frameworks, since frameworks carry their headers
inside. However, this change came too late for Qt 5.1 for us to assess
the potential impacts -- it's known to break at least the cmake files we
ship.
So restore the build to the way it was.
This is a partial revert of 6d61dfdbb7.
Partial because the old behavior was partially broken: it did not
install headers for release builds. Now we always install (and in
debug-and-release mode, we might do it twice).
Task-number: QTBUG-32134
Change-Id: Ib84879c5a148d3717d16a7a90b2f5735fb5d80be
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
only the include statements found in public headers are constrained to
work with this flag. our own c++ files and private headers can use other
styles, which this flag breaks.
Change-Id: Icb1ced17dc438083731049788ac28349c87ba7ef
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
they are a somewhat different kind of private headers, but follow
generally the same logic.
Change-Id: Ic6f42ed7061dde2ffd0e32b1d713354b58a20970
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
We handle C++11 and libc++ through c++11.prf now, so separate mkspecs
are not needed. Deprecating them allows us to remove them in a later
release.
Change-Id: I4e525f445aeab88c926fa62cedef6aa9b32a7f55
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
the entry for the normal headers already ensures that there is the
correct version symlink. having an entry for the private headers as well
is pointless, and in fact clobbered the symlink for the actual library.
Change-Id: I2403761bf006b7bfa490ce85c7b0e46d5ef203c0
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
There have been fixes done to the MSVC qplatformdefs.h that aren't
reflected in the ICC one -- specially the inclusion of
windows.h. Since ICC is never tested, simply defer to the MSVC one and
hope it's enough.
Task-number: QTBUG-30839
Change-Id: I3c22638cc7fac3399d3606b1583608e95208df6e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
the only case where we want to skip copying the bundled data (which is an
optimization only) is the debug sub-build when we are actually building
both debug and release.
Change-Id: I1f3f67ccd9a64033b133ffaf58639cd9f7107c27
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
i see no particular reason why debug builds should still get
"normal" headers.
Change-Id: I3625648549e8c234a365bab26823190ed2219cdf
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
there is no point in adding a structure we don't actually define.
Change-Id: Ica43123f17eca6ebd4b5b7ec2526ebabef31c82a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
it's cleaner, and it makes it possible to actually have a single else
branch.
Change-Id: I5ef917b678e2bd5a2face8ee19e942e5e952aa80
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
don't mess with the -F linker flag manually. qt headers include other
headers via the canonical Module/Header syntax, which means that the
compiler also needs the -F flag. QMAKE_FRAMEWORKPATH does exactly that.
Task-number: QTBUG-29003
Change-Id: I5f4af1a462697cd6996c54436ccdb9fc2b216020
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
... except for MAKEFILE_GENERATOR = XCODE. This means the spec no longer
hard-codes g++, and will work regardless of whether the default spec was
clang or g++.
This require us to set QMAKE_XCODE_GCC_VERSION properly for GCC, so that
additional compilation flags passed by Xcode will match the actual
compiler used.
Task-number: QTBUG-31713
Change-Id: If65140a7471cd16f483036742f1d5b86d0485c52
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Otherwise doing stuff like -spec macx-g++ when the default spec is clang
will not have an effect on the tools used.
Change-Id: Ia2769abfdd8c19f79d427b9f09707430e736305a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
