The output directory may be the same as the source directory in
the case of an in-source build, but Xcode treats the SYMROOT as
a build directory, and automatically excludes it from Time Machine
backups, which may result in not backing up sources.
Instead we map SYMROOT to an .xcode subdirectory of the output
directory, and then use CONFIGURATION_BUILD_DIR to make sure
the final build targets end up where they used to.
Task-number: QTBUG-52474
Change-Id: I3852ca9088e75ca62fca4c1217b5485175d9436f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This ensures that the generated XCode project can correctly find any
files that are referenced via a path containing "..".
Task-number: QTBUG-35131
Change-Id: I049bc2279b4c515a82acd61142d25b8c240e8f6e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Since Xcode 6.3, this must be set to NO because stripping on copy is no
longer fully supported due to the potential of input binaries being code
signed. In this case Xcode will simply ignore the strip step and issue
a warning since stripping would invalidate the code signature. This
change silences that annoying warning for release builds. Also, the
setting assignment is moved from being hardcoded in the generator, to
a QMAKE_MAC_XCODE_SETTINGS value.
Change-Id: If25511edddc12b7b0407e2992d80884b7d6437dc
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
In Xcode, the default value for GCC_GENERATE_DEBUGGING_SYMBOLS is YES,
which causes Xcode to emit debug symbol bundles (.dSYM) on macOS and iOS
*if* DEBUG_INFORMATION_FORMAT is also set to dwarf-with-dsym. Since that
setting is already set to an appropriate value with debug vs release
builds, the default Xcode value for GCC_GENERATE_DEBUGGING_SYMBOLS is
already correct and in effect the only thing qmake was doing was always
setting GCC_GENERATE_DEBUGGING_SYMBOLS to a wrong value for release
builds - it should be YES in all cases, to allow the .dSYM bundles to
be generated in release mode, which is in fact the only case where
they're really needed in the first place.
Task-number: QTBUG-41246
Task-number: QTBUG-50896
Change-Id: I07639a3c4ff9f62d591cde3ad66748767d475e3b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Task-number: QTBUG-59301
Change-Id: I2562b862465a52ecc56f551bcdb98fa7279ebfcf
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
Adding both development team and provisioning profile to Xcode
switches off the automatic signing
Task-number: QTBUG-38782
Change-Id: Ic869e16490c11e369b6674c815e860cac66c5afa
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
This ensures at compile-time that Qt libraries do not use any APIs that
are not safe for use in application extensions, and fixes warning
messages that appear when linking to Qt libraries that are not built
with this flag, when used in an application extension.
This is especially important on watchOS where *all* "applications" are
actually application extensions, and on other Apple platforms if
application extensions are developed using Qt.
Task-number: QTBUG-40101
Change-Id: I022046f2584e0222253d33052b0abc221d7c93d6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
These code paths have not needed to be exercised since Xcode < 3.2 was
dropped from support, which is beyond ancient at this point.
Incidentally, this removes use of a deprecated function.
Change-Id: I3e5a45794c21b434b31a48da8a8b0ff22f2852fa
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Slims down QCFString and leaves only one implementation of converting
back and forth between CF/NS strings and QStrings.
Change-Id: I068568ffa25e6f4f6d6c99dcf47078b7a8e70e10
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
This version now prefers non-free provisioning teams, since the latter
seem to be problematic in more cases.
Task-number: QTBUG-55915
Change-Id: Ie40ddae5e333acdd5327ed46992fb4fb300dee25
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
5971b88e is not needed in new configure.
This merge also reverts "fix QMAKE_DEFAULT_*DIRS resolution with
apple SDK", 2c9d15d7, because it breaks iOS build with new
configure system.
Conflicts:
mkspecs/features/default_pre.prf
mkspecs/features/mac/toolchain.prf
mkspecs/features/toolchain.prf
src/dbus/qdbusconnection.cpp
src/plugins/sqldrivers/mysql/qsql_mysql.cpp
src/sql/drivers/mysql/qsql_mysql.cpp
src/widgets/widgets/qmenubar.cpp
src/widgets/widgets/qmenubar_p.h
tools/configure/configureapp.cpp
tools/configure/environment.cpp
tools/configure/environment.h
Change-Id: I995533dd334211ebd25912db05b639d6f908aaec
This makes the Xcode generator smarter so that it recognizes when
a QMAKE_BUNDLE_DATA entry is attempting to embed a framework,
dynamic library, or plugin into the application bundle, and
places it into the correct generated PBXCopyFilesBuildPhase.
Change-Id: I67ac1534a0521eecfc90537db6f9aca2bdbc96b0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
This fixes a bug where joined device and simulator builds would get
for example, QtCore_iphonesimulator as the CFBundleExecutable.
According to Apple:
"For frameworks, the value of this key is REQUIRED to be the same as
the framework name, minus the .framework extension."
This does not affect the ability to load a framework whose executable
name differs from the bundle name (as is the case for simulator builds),
as the application will be linked to the correct framework executable
at link time by specifying (for example) the linker flag:
-framework QtCore,_iphonesimulator
Change-Id: Ib7614670d0620e0235cd7e2606d42dd034a90c68
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
This is a prerequisite for properly constructed framework bundles.
On certain Apple platforms (iOS, tvOS, watchOS), bundles are used
in "shallow" format, meaning that the directory structures are
flattened compared to the one used in macOS bundles.
shallow_bundle allows the difference to be expressed independently
of the platform. Note that the term "shallow bundle" is used by
Apple in Xcode internals.
Change-Id: I1189c52b0ea66843c313783176c11cc2af97ad25
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Pass -xplatform macx-tvos-clang to configure to build.
Builds device and simulator by default.
Added ‘uikit’ platform with the common setup.
Also added QT_PLATFORM_UIKIT define (undocumented).
qmake config defines tvos (but not ios).
tvOS is 64bits only (QT_ARCH is arm64) and requires bitcode to be
embedded in the binary. A new ‘bitcode’ configuration was added.
For ReleaseDevice builds (which get archived and push to the store),
bitcode is actually embedded (-fembed-bitcode passed to clang). For all
other configurations, only using bitcode markers to keep file size
down (-fembed-bitcode-marker).
Build disables Widgets in qtbase, and qtscript (unsupported,
would require fixes to JavaScriptCore source code).
Qpa same as on iOS but disables device orientation, status bar, clipboard,
menus, dialogs which are not supported on tvOS.
Change-Id: I645804fd933be0befddeeb43095a74d2c178b2ba
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
Xcode does not recognize "<Group>" with a capital G, only "<group>" with
a lowercase g. As a result, paths of files within these groups are
calculated incorrectly. For example, dragging any external file into the
Xcode project would result in its leading slash being removed (while
still treated as an absolute path - broken reference). Furthermore, the
dropdown in Xcode displayed the Group location as an invalid string
instead of the correct "Relative to Group". This patch restores correct
behavior.
This fixes a regression introduced in
f09ec09c208c75a16abe05b6bb505a1fc58775a6.
Task-number: QTBUG-52701
Change-Id: I9af5360049a79e7958301e4090a9a542bab0af8c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
evidently, nothing and nobody sets this option, as it's been completely
broken since 6234dec41f (qt 5.5) and apparently nobody noticed.
Change-Id: I5a82ebd963a292af4689397875dde096f63d751a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
(or trivially marked const) ... by replacing them
with C++11 range-for loops.
Change-Id: I1522e220a57ecb1c5ee0d4281233b3c3931a2ff8
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
... by replacing them with C++11 range-for loops.
To avoid detaches of these mutable Qt containers,
wrap the container in qAsConst().
Change-Id: If086bea06fe26232a7bb99fad8b09fce4dc74c27
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
... by replacing them with C++11 range-for loops.
The functions QMakeProject::values(), QMakeMetaInfo::values()
and QHashIterator::value() all return by const-reference,
so they can be passed to range-for without further changes.
Change-Id: Ic3b39ed8ff8cd7a6f287f1aa9d61a1acd67d7aaa
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
From Qt 5.7 -> tools & applications are lisenced under GPL v3 with some
exceptions, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new GPL-EXCEPT header instead of LGPL21 one
(in those files which will be under GPL 3 with exceptions)
Change-Id: I42a473ddc97101492a60b9287d90979d9eb35ae1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
The Xcode generator iterates trought all libraries and replaces
their suffix (e.g "_debug") with a placeholder that lets Xcode
switch between different library versions depending on the target.
The current way we do this fails when the name of a library happens
to contain the string "_debug" (e.g "qmldbg_debugger"). Since we
replace every occurrence of suffix in the path, we end up
replacing that part as well. The result will be linking errors.
This patch ensures that we only replace the last occurrence of the
suffix in the file path.
Task-number: QTBUG-48961
Change-Id: I9fafbe0ea0ad8b9cfd13448d6b28801106e645ec
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
Instead of lumping both Objective-C (.m) and Objective-C++ (.mm) sources
into the same pile, passing them on to the same compiler as for C++ (CXX),
with the C++ flags (CXXFLAGS), we follow Apple's lead and treat them as
variants of the C and C++ languages separately, so that Objective-C
sources are built with CC and with CFLAGS, and Objective-C++ sources
with CXX, and CXXFLAGS.
This lets us remove a lot of duplicated flags and definitions from the
QMAKE_OBJECTIVE_CFLAGS variable, which in 99% of the cases just matched
the C++ equivalent. The remaining Objective-C/C++ flags are added to
CFLAGS/CXXFLAGS, as the compiler will just ignore them when running in
C/C++ mode. This matches Xcode, which also doesn't have a separate build
setting for Objective-C/C++ flags.
The Makefile qmake generator has been rewritten to support Objective-C/C++
fully, by not assuming that we're just iterating over the C and C++
extensions when dealing with compilation rules, precompiled headers, etc.
There's some duplicated logic in this code, as inherent by qmake's already
duplicated code paths, but this can be cleaned up when C++11 support is
mandatory and we can use lambda functions.
Task-number: QTBUG-36575
Change-Id: I4f06576d5f49e939333a2e03d965da54119e5e31
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
don't look up the files and normalize the paths multiple times, as this
is inefficient and hard to understand.
on the way, processPrlFile() got unnested, and libExists() got nuked.
note that a missing QMAKE_PRL_TARGET will be now complained about, which
really should never happen.
Change-Id: Ibcd77a7f963204c013548496ecd2d635e1a4baba
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
there is no reason to expect the various list elements to be
space-encumbered, or to tolerate it if they were.
Change-Id: I1a2e5c8d30456b640408503334c55f9262792db5
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
With Xcode7, Apple added support for compiling apps to bit code
instead of binary (*). But this is only supported when the deployment
target is at least 6.0. And in Qt-5.5, the deployment target is
still set to 5.1.1. The result is that every Qt application will fail
building once people move to Xcode7.
Instead of bumping the deployment target (which we plan to do
for Qt-5.6), we choose to switch off bit code for now.
*: https://developer.apple.com/library/prerelease/ios/documentation/IDEs/Conceptual/AppDistributionGuide/AppThinning/AppThinning.html
Change-Id: I23001563439a7726506b7cd2dc77a82533b8a27b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
since commit 22edeb3f4 (private; anno 2002), the generator would extract
-prebind and translate it into a PREBINDING property in the pbx file.
the writeout to the pbx file got lost in the rewrite for Xcode 3.2
(commit 66f6e5b1; anno 2012).
this isn't particularly bad, as prebinding is obsolete since OS X 10.3.4.
we now go the last mile and remove the handling of the flag. that means
that remaining projects which still use it (meaninglessly) will get a
warning from Xcode, which is kinda what we want.
QMAKE_LFLAGS should have never been part of the library iteration loop.
it was added there in the prebind handling commit, so we can get rid of
it again now.
Change-Id: Id7dee2b1e248bb2bd7aa7a3e66f82057921afffd
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
Currently, the Xcode generator uses "sourceTree = <absolute>" for
all PBXFileReferences. But the paths we use for referencing
libraries are relative. This patch will change this, so that we
always use absolute paths to be consequent.
This will fix a crash in Xcode that happens when opening
projects generated by Qt.
Change-Id: I3a372b93598a777c96ba353205cf19710a5923f5
Task-number: QTBUG-45966
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
ProjectBuilderMakefileGenerator::openOutput should only change back
Option::output_dir when creating a pbx file inside an Xcode project.
Since the pbx file will be placed inside a different directory than
output_dir when creating an Xcode project, MakefileGenerator::openOutput()
will redirect output_dir to be inside the Xcode project as well. Since
we don't want this redirection, we change output_dir back to what it
was once the call returns. But we should only do this when creating
the whole Xcode project, since only then we create a pbx file that
is different from output_dir in the first place.
A bug with this is seen when making qt_makeqmake.mak (which is a
helper makefile inside the Xcode project). That file will only
regenerate the pbx file (and not the whole Xcode project), which
means that we don't enter the fileName.isEmpty() section, which
means that output_dir should stay as it is.
Task-number: QTBUG-45826
Change-Id: I03d5c3dec395ff4768f9272fd1981c6fd35efb1e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
instead of allowing arbitrary input and output base paths, restrict them
to the project input and output dirs (in any permutation), which are the
only cases ever used anyway.
this permits much clearer call sites, and allows later optimizations.
Change-Id: I48d149a4417af5c858e66ec57c476a5bc6b17f17
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
explicitly use the correct directories instead of temporarily changing
into the output dir. this makes the code less obfuscated.
Change-Id: Ia935987f486151ae556910703cc20945c7610ffc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
turns out that a relative path makes some versions of Xcode crash.
so use an absolute path again.
fileFixify() has been fixed for shadow builds to make this possible.
This reverts commit 6ccf0a326e.
Task-number: QTBUG-45424
Change-Id: Ica87c6c29f990f56e42c399b6d9b1c7eacdd13a7
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
