prelink was not supported at all for ar.
postlink was done for most cases, but missing in one particular ar
invocation.
Task-number: QTBUG-57276
Change-Id: Ic72c42a9502c97d7111b3f3941b387024d46a27d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
[ChangeLog][QtBase][General] Removed support for WinRT/Windows Phone 8.1.
Task-number: QTBUG-57288
Change-Id: Ifd6d6780cbbdb710d99556ba3d2fb2e514d4f789
Reviewed-by: Oliver Wolff <oliver.wolff@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>
When generating the Visual Studio project XML, the filter "Root Files"
was not being output. Specifically, this means that even if RC_FILE was
specified, it would not be included properly as a resource compilation
target in the resultant Visual Studio project file.
This is essentially a rather belated cherry-pick of qt/d6de960b7f.
Task-number: QTBUG-57914
Change-Id: I7d03dc818df0cf36608012f1a71a3a476d8a9ff7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
the arguments after '--' are by definition meant only for the top-level
project, as that's where configure is invoked from. passing them to
sub-projects just adds noise to the make output and misleads users.
note that this specifically does not support qmake -r, which will break
if the subprojects rely on the arguments being absent. this isn't a
problem, because the qt build doesn't support qmake -r anyway.
Change-Id: I7ecff6212ce3137526005fc324a4a7ae45e3345e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
turns out that just appending builtin-qt.conf isn't a good idea:
executable-editing tools (objcopy, prelink, etc.) will happily drop the
"attachment".
a safe method would be adding a proper section to the executable, but
there doesn't appear to be an objcopy equivalent in msvc, and using
entirely different methods of embedding the file with different
toolchains seems like a rather bad idea.
so instead go back to the old method of building qmake with a generated
qconfig.cpp. of course, as said file is now created by qmake itself, we
have to compile qlibraryinfo.cpp a second time, and link a second qmake
executable.
Task-number: QTBUG-57803
Change-Id: I9e232693550aa870cec154e49cc06add13017cc2
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Most of these involved moving or removing extraneous
aide-memoir comments left by programmers between qdoc
comments and their functions. There were also some
cases where Q_CLANG_QDOC had to be tested to make
something visible to clangqdoc. And there were a few
functions that should not have been documented at all.
Change-Id: I3bf7c397a9e5ddbffc40cc1fee7f19cad71a1ae7
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
now that configureapp does not use it any more, qmake is the only
remaining user. and the license headers already claimed that this code
is part of qmake ...
Change-Id: I9b8a16f8f2b432d2b1143efbdd1f0042305ccc0c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since we can tell the MSVC version from the compiler now, each of the
qmake.conf files is now the same, so let's just have "win32-msvc" and be
future-proof. Likewise for win32-clang-msvc.
qplatformdefs.h was already common.
Since we can't obtain the MSVC version from the unified mkspec name any
more, I dropped the warning level during the qmake bootstrap to reduce
the number of warnings that need to be disabled from compiler version to
version.
There is no point in keeping the old mkspecs, but configure will re-map
the -platform argument to the unified spec as necessary, to keep
existing configure command lines working.
[ChangeLog][Visual Studio] Qt now has a common mkspec for all Visual
Studio versions, called "win32-msvc". The old names which contained the
version number are now gone (but qmake scopes based on the old names
continue to work). The version of the compiler can be obtained from the
MSC_VER and MSVC_VER variables (for example, for Visual Studio 2015,
those contain the values 1900 and 14.0, respectively). Those variables
are also available with the Intel compiler (win32-icc) and with Clang
(win32-clang-msvc).
Done-with: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Change-Id: Ib57b52598e2f452985e9fffd14587c0a77a5c09c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
the code was broken since 5.0, as it still hardcoded the version number
4 for the plugin basenames.
wince is not supported any more, so there is no point in trying to
restore the code to function.
at a later point, we'll make QTPLUGIN universal enough to cover both
static and dynamic deployment.
Change-Id: I0911ce4aff7a799dd471d6218e046f13dca6d49e
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Before VS 2013 ToolsVersion contained a .NET version
number (e.g. "4.0"). Since VS 2013 ToolsVersion is the same as the
Visual Studio version number (e.g. "12.0"), which is also the default.
We always wrote "4.0" (except in one special case which used
"14.0"). This doesn't bother Visual Studio itself, but other tools
like PVS-Studio.
Remove the ToolsVersion attribute from generated VS projects for VS
2013 and newer.
Task-number: QTBUG-57694
Change-Id: I7a3bc4534c492e9540f6b968bee8a969980df63f
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Change dcd2f829 introduced fake files with the extension .cbt for custom
build tools that generate code from C++ source inputs. The moc_predefs.h
header file falls into this category, because it is generated from
dummy.cpp.
It turns out that these fake files have to exist. Otherwise the
custom build step is executed on every build. That means re-moccing all
mocables on every build.
Fix this by actually creating the fake .cbt files with some
explanatory comment in them.
Task-number: QTBUG-57695
Change-Id: I251294334425d9914677787d8ba6da1169b4cca5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
there is no point in iterating BAR if FOO is (or became) empty.
Change-Id: I86c89bf0ad726a5ab7ead990a27ef7cc32caebbf
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
this is of marginal value, as only our own code ever messes with
QMAKESPEC, and we mostly stopped matching on the spec in favor of
compiler and platform flags.
Change-Id: Ibdd9a9c85067623f0f1f064d139d23b4e6b0677d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
since ab0cc305, the spec will be replaced by an entirely new one during
configuration, and so needs to update the path separator for
$$shell_{path,quote}(). however, the latter didn't happen, as the spec
reloading doesn't go through the "real" spec loading path.
Change-Id: I45ab3156b8e040f683328ac46e48b09c2eb94ef7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This tag was never spelled "PlatformToolSet". The correct spelling
is "PlatformToolset" (lower case s). VS itself can load qmake-generated
projects despite this misspelling, but tools like PVS-Studio are
bothered by it.
Task-number: QTBUG-57435
Task-number: QTBUG-57694
Change-Id: Ib70e8561f1827e195194bcf518445b2909a8d8c0
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
this moves us another step towards the "outer" configure doing just
minimal bootstrapping of qmake.
a challenge here was that so far, qmake itself needed qconfig.cpp. this
was replaced by usage of a qt.conf file instead of compiled-in values.
however, to make the executable still self-contained, that qt.conf is
embedded into it (by simple appending of a fixed signature and the text
file).
the qmake with the embedded qt.conf is not used for the qt build itself,
which instead relies on the qt.conf in bin/ as before. however, due to
the missing built-in values, this file now needs to contain more
information than before. but except for a minimal version that is needed
to start up qmake/configure at all, that file is now also generated with
qmake. as some of the newly set up properties are subsequently used by
configure itself, qmake gains a (deliberately undocumented) function to
reload the qt.conf after it's fully populated.
unlike the old implementations, this one doesn't emit redundant qt.conf
entries which match the hard-coded fallbacks. omitting them leads to
leaner files which are more comprehensible.
Started-by: Paolo Angelelli <paolo.angelelli@qt.io>
Change-Id: I4526ef64b3c89d9851e10f83965fe479ed7f39f6
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
otherwise, infinite loops can result, as amply demonstrated by the new
configure (which duly replicated the old configures' behavior ...).
QMakeEvaluator::evaluateBuiltinExpand() now returns a VisitReturn like
all other evaluate*() functions. the string list return value is now an
out parameter; i used a reference instead of a pointer to avoid
adjusting 56 usages of it.
Task-number: QTBUG-13964
Change-Id: I51ca7df8d694c6ffe9d9899cba414b1b46f5ce95
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The phrase "which as been" lacked an h (albeit one silent in some
anglic dialects). The added letter made an already long line stick
out just a little more. Judicious rephrasing of the early part of its
sentence made reflow a way to fix that.
Change-Id: I29c2ac79d08a135dd4a16518f459872c8ecd1f24
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
eliminating everying TARGET-related was a nice try, but in the real
world (e.g., qttranslations), extra compilers are activated by
PRE_TARGETDEPS, which of course doesn't work when TARGET is entirely
gone.
so instead, let it act as a phony target. this is consistent with the
unix generator.
supersedes 0810d48bc in amending af2847260.
Task-number: QTBUG-57423
Change-Id: I3d2ecc4ff42b37ffe5f71f5c20d17c06b31f4da2
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
For QMAKE_EXTRA_COMPILERS with inputs that are "buildable" (e.g. C++
sources) the custom build step is added to the output file. From Visual
Studio's point of view this looks like a circular dependency (e.g.
foo.moc generates foo.moc). Usually this just prints a warning that can
be ignored. But this circular dependency also breaks dependencies
between custom build steps. This became noticeable when the generation of
moc_predefs.h was added. Generating moc_predefs.h must be done before
any moc custom build step is executed.
This patch fixes the issue by using fake files (output file plus suffix
".cbt" for "custom build tool") that act as dummy inputs for the custom
build tools.
Task-number: QTBUG-16904
Task-number: QTBUG-57196
Change-Id: I4711e44a0551046d215db151fa0312af8a9177a2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
it's wrong to use the escape function for makefiles, as the command
goes directly to a popen() call.
Task-number: QTBUG-57343
Change-Id: I34a8e4d8fb406303c593e7c1e24019e0f756e7f8
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
The values of this hash are strings, not lists of strings.
Enforce this by using the proper type instead of just using a comment.
Change-Id: Id8a13acdceb8f9f8a9a8eaa04e790b1e6cd5faa7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
of course, we should stub out everything related to TARGET - only the
generic "all" and "first" targets including their deps should be
emitted.
amends af2847260.
Change-Id: I8ed7a550b8022c69328d2e16dbd078928d176964
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
actually pack the extra compilers' input files, not the variable names.
unlike on unix, we don't create an actual distdir, so the package is
still going to be rather broken.
Change-Id: If0a15bbe9db95aebd88c2a21ca3c0f787ce5c7e1
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
... instead of having (duplicated) code in the configures to create it.
Change-Id: Ia86b44021a024a969f5a49b7fb18d3d414869f93
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
so far, qmake.exe was built in qmake/ and then copied to bin/, with
possible errors in the second step ignored. this made no sense.
this unifies the nmake makefile with the unix one; compare 46e51ce1d.
Change-Id: Ieb9c7cd46f0be0501d17e297808ac1cdad1b3c4a
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
when the file's effects are discarded, the mention of the file should be
as well.
Change-Id: I894b7e2b887dd34d18533b197bfa9d0d84d647e7
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
the normal mode forces the prompt into a pattern which may be
undesirable.
Change-Id: I01689c7a6573415801862348b32bafc6a609ed4a
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
that is, adjust path separators and don't quote them. we already did
that to some degree, but totally inconsistently, so it just didn't work
for any targets with "fancy" file names.
note that we don't bother doing that for recursive targets, as these are
assumed to be identifiers.
Change-Id: Ic75f003b71abc6fed03a4121b903ad5ee8253ed2
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
there are plenty new functions, let's do this symbolic act.
Change-Id: Iaeb88afa5e33cacd81dc0ea26e380a16af06a739
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
We can not improve the result from JSON parsing without changing API,
so instead recalculate the line and column based on input and offset.
Change-Id: I54149233f71023aa5d30deff854d6f3406c5c48c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Replace which_dotnet_version with a simple function that converts the
value of MSVC_VER to its corresponding enum value in the VS project
generator.
This reduces the maintenance burden when adding support for a new VS
version, because we do not need to update the registry keys in
which_dotnet_version anymore.
The which_dotnet_version function implemented the following logic:
- find all installed VS versions via registry
- select the "best matching one"
- if there is no best match, select the VS that's in PATH
- create a project for that VS installation
The usefulness of this whole stunt is questionable as the VS version of
Qt's mkspec must match the version of a project using that Qt anyway.
Change-Id: I9fb9a099ee5ddb5fc4c450be4f68f41f2b406b9a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
sysroot, spec, and xspec have no /src and /get variants.
Change-Id: I8548791f8ea6ba9fd9f10c35f914ed6badbea9d4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
the autotest was also broken, because it was created by pasting the
bogus message into the result ...
Change-Id: I02b8663b96c7d96cdb3c19639e2213e49fd2bcec
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
On the way to get rid of this function.
Have one place to determine the VS version instead of calling
this function over and over again (even though all calls but
the first are cheap).
Change-Id: Ic42a65df5a9bbe289f4813e4db85000dba15e672
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Make qmake understand the /DEBUG:FASTLINK option in QMAKE_LFLAGS, and
write the corresponding value correctly to VS 2015 project files.
Task-number: QTBUG-55591
Change-Id: I670375ed1523a5ab96bb3cce28635785564edba8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Commit 3d3d65f5 separated the PDB files for compiling and linking. Only
the PDB file the linker produces would be installed. However, this does
not work for static libraries as the LIB tool does not create a PDB file
from the compiler's PDB file. This patch turns the separation between
PDB files off for static libraries.
Task-number: QTBUG-56594
Change-Id: I08dcb7889c67b2f6370efa1ee19be8558355bbc9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Following the discussion at QtCS 2016 about deprecated APIs,
let's enable the warnings by default.
Change-Id: I73fe63de3e4f755067100320d7497b6b227549b6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
If the application's Info.plist contains the key
'NSPhotoLibraryUsageDescription', we know that we can safely link in
qiosnsphotolibrarysupport without violating AppStore requirements.
This is a simple feature that doesn't introduce additional qmake
API for doing app deployment with optional iOS QPA plugins.
[ChangeLog][iOS] Starting from iOS 10, Apple requires all apps
that need access to photos to have the key
'NSPhotoLibraryUsageDescription' in the Info.plist.
Therefore, to get the same support in Qt (when, e.g., using
a file dialog), the Info.plist assigned to QMAKE_INFO_PLIST
will need this key as well.
Change-Id: I7a93afe24b589cad96d5a1d9e2a155ad1671178a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Add a qconfig-bootstrap.h, which contains all the defines required
to build the bootstrapped tools. This will be required anyway when
moving more code over to use QT_CONFIG(foo) instead of QT_NO_FOO.
Change-Id: I783d0aa0100b9190fe2d422bee4a95b05720aebe
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
necessary for use outside qmake itself.
amends f137957e08.
Change-Id: Ie069f7b6efc969ab112e1f0ecd966eb06248fb94
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@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>
so far, we "downgraded" only explicit error() output, but other errors
may happen as well while doing semi-exact evaluation of .prf files - at
least hypothetically.
amends 08d0cb6f8e.
Change-Id: I32819a569dbed2dbdb37c5c23bf4a5a18d3c64ea
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
(cherry picked from qttools/ea1a5c3534f089c0e704808a0fb029eda8f753b4)
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
With the removal of Windows CE support(52623d6d) the logic of these
checks have changed, as it was always true for non Windows CE builds
before.
This did not affect WinRT, as those mkspecs define VCPROJ_ARCH
explicitly in their qmake.conf.
Task-number: QTBUG-55753
Change-Id: Ie2eddf197c17fcbf7343b444cfe8940a332a545c
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@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 class provides a "type safe" way to compare and access operating
system version numbers.
[ChangeLog][Deprecation Notice] QSysInfo::windowsVersion() and
QSysInfo::macVersion() are deprecated and are replaced by the newly
introduced QOperatingSystemVersion.
Change-Id: I52b532de2e068ccf90faaa8342eee90c0a4145de
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Parsing the other files will (re)generate the same metaobject info in two places
Change-Id: I8984ed30751a7587de870f55dd427f067d1b2495
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
The actual blocker for precompiled headers is not the iOS/tvOS/watchOS
platforms, but the way qmake handled multiple-architecture builds on
Apple platforms.
This patch allows multi-arch builds to be performed while using
precompiled headers.
Since df91ef3d6c55692a0236f67b6c6b134a3bf84098 (April 2009), Clang has
had support for PCH files in the driver, which allows to use the
-include flag to automatically translate to -include-pch. We can then
take advantage of the fact that the -include option is allowed to not
be separate from its argument, which lets us take advantage of -Xarch to
specify a per-architecture precompiled header file.
This is done through some magic in the qmake Makefile generator which
"multiplexes" the PCH creation rule across multiple architectures and
replaces a series of tokens with the proper precompiled header paths
and architecture flags at usage point.
Change-Id: I76c8dc9cda7e218869c2919f023d9b04f311c6fd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
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>
CFURLCreateDataAndPropertiesFromResource and
CFURLWriteDataAndPropertiestoResource have been
deprecated since 10.9. We replace them with simple
QFile access.
Code cleaning and included.
Change-Id: I19c7ceac41c8c511962f1128bd8e210e3adb434c
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
cf53aa21bf and 3aaa5d6b32
were reverted because of reconstruction in 5.7.
defineTest(qtConfTest_checkCompiler) in configure.pri is smart
enough to cover the case in a9474d1260.
DirectWrite: Fix advances being scaled to 0
Since 131eee5cd, the stretch of a font can be 0, meaning
"whatever the font provides". In combination with ec7fee96,
this would cause advances in the DirectWrite engine to be scaled to
0, causing the QRawFont test to fail.
Conflicts:
configure
mkspecs/features/uikit/device_destinations.sh
mkspecs/features/uikit/xcodebuild.mk
src/corelib/global/qglobal.cpp
src/corelib/global/qnamespace.qdoc
src/plugins/platforms/cocoa/qcocoamenuitem.h
src/plugins/platforms/windows/qwindowsservices.cpp
src/plugins/platformthemes/gtk3/qgtk3dialoghelpers.cpp
src/plugins/platforms/windows/qwindowsfontenginedirectwrite.cpp
src/widgets/kernel/qapplication.cpp
tests/auto/widgets/dialogs/qfiledialog/tst_qfiledialog.cpp
tests/auto/widgets/dialogs/qfiledialog2/tst_qfiledialog2.cpp
Change-Id: I4656d8133da7ee9fcc84ad3f1c7950f924432d1e
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>
