qmake expects the generator to be the same for each node in the tree
of subdirs, including the leaf projects, which caused failures when
qmake tried to recurse out to the leaf projects and run 'make', when
the leaf project was an Xcode project.
We now wrap the Xcode project in a meta-makefile that just
calls out to xcodebuild to do the actual work. This allows us
to get rid of the hacky generator detection, and use the macx-xcode
mkspec instead of setting the generator, which is much cleaner.
Change-Id: I2fed6a4dd6343b6a320eb459ecae824553bff459
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
To instrument a Qt application or library with the gcov coverage
tool, do `CONFIG+=gcov' in the application .pro file.
To instrument Qt itself with gcov, use the `-gcov' configure
option.
Change-Id: If24e91d95318609b0df1a76ed6d679bd92bcaab2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
... 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>
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>
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>
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>
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>
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>
If Qt was built with C++11, it links to libc++, and we need all projects
that use Qt to link against the same library.
Technically, we could do QMAKE_LFLAGS += -stdlib=libc++, but that hasn't
been tested enough without also enabling C++11, so we keep the
relationship between the two for now.
Change-Id: Ic628bcbade60cc82f93707f372c2119c24d9dc8a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Liang Qi <liang.qi@digia.com>
The cmake variable for the mkspec dir must specify the source
location if used in the build dir, and must specify the install
location if used in the install dir.
Change-Id: I2fee8cd0c7198e9fc5cbb63972e20c75636672d1
Reviewed-by: Thorbjørn Lund Martsum <tmartsum@gmail.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
