When QMAKE_TARGET_BUNDLE_PREFIX is set in the .pro file then
this value should be used instead of the default value for
PRODUCT_BUNDLE_IDENTIFIER. Therefore, PRODUCT_BUNDLE_IDENTIFIER
should be set inside default_post.prf so that it can take the
value of QMAKE_TARGET_BUNDLE_PREFIX after it may have been set.
Task-number: QTBUG-66462
Change-Id: Iec1e2a43632efe6021b9d6bfdb78bd941326c456
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
instead of pre-resolving them and passing the final LIBS to qmake, pass
raw QMAKE_*_LIBS* assignments and a QMAKE_USE stanza. the immediate
benefit of that is that it centralizes the debug/release lib handling,
which makes build variant overrides available to all libraries, not just
a few selected ones.
note that this removes the CONFIG+=build_all from the test projects.
turns out that this was ineffective to start with, as config tests are
built with an explicit CONFIG-=debug_and_release. we might re-instate it
in a non-broken way later on.
Change-Id: I2117c5b36937e8230bd571dcee83231515cbe30b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
this de-noises the code somewhat, and makes it possible to eval() the
code generated by $$qtConfLibraryArgs(), which we want to do later.
Change-Id: Ib6101c6745101801e34f8fab1ad6651e624130c7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add support for QSurface::VulkanSurface and QVulkanWindow.
Usage:
1) Build MoltenVK according to instructions
2) Configure Qt: ./configure -I /path/to/MoltenVK/Package/Release/MoltenVK/include
3) export QT_VULKAN_LIB=/path/to/MoltenVK/Package/Release/MoltenVK/macOS/libMoltenVK.
Implement support for QSurface::VulkanSurface by enabling
layer mode for QNSView and then creating a CAMetalLayer,
which the MoltenVK translation layer can run on.
MoltenVK provides an implementation of the Vulcan API,
which means that the platform integration is similar
to other platforms: implement a QCocoaVulkanInstance
where we pass the QNSView instance to the vkCreateMacOSSurfaceMVK
Vulkan surface constructor function.
Using Vulkan directly without QVulkanWindow is possible, but not
tested.
We currently load libMoltenVK at run-time and use the
existing QT_VULKAN_LIB environment variable to set its
path. For deployment purposes it would be better to
link against MoltenVK.frameworkm, but this
Task-number: QTBUG-66966
Change-Id: I04ec6289c40b199dca9fed32902b5d2ad4e9c030
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
relative paths must be resolved against $$OUT_PWD, not $$_PRO_FILE_PWD_.
Task-number: QTBUG-58991
Change-Id: I9ce8e9c78e0fad026a7cc355852d23f9d6e96ee6
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
using qt$$MODULE isn't enough if the module is composed of submodules
which need the final module's headers, because that would require two
modules having the same module .pri file.
the first thought to fix this was to just use $$lower($$TARGET), but
that breaks for testlib (QtTest). while the config file name isn't
public api, it's included by a public header, so changing it is risky.
so instead stay with the original pattern, but make it explicitly
overrideable.
Change-Id: I758c46ed403620620d577ae16866ce751271b63e
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Add qmake feature and configure option, which optimze the size of static
exectuable. Use for static build.
Enabled via configure --gc-binaries, or CONFIG += gc-binaries in 3rd party
projects.
Change-Id: I3c25b02caaef6a4afc6019afc9c67122dd11696d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
We need to make sure we don't emit CMake declarations for private
headers if those headers are absent. However, most of the time we have
private headers and should add them.
Task-number: QTBUG-37417
Change-Id: I639eb93d008de27928dedac540894af70c1883b9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Writing out the $TARGET_plugin_resources.cpp file in !build_pass breaks
when TARGET is adjusted by $qtPlatformTargetSuffix values. We end up
writing out $TARGET_plugin_resources.cpp but the debug Makefile looks
for $TARGET_debug_plugin_resources.cpp.
Try using the pro file name as name source instead, as suggested by
Ossi.
Task-number: QTBUG-67931
Change-Id: I221cf9b2ec1db699568d0c73513aa66ecf0ada97
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
don't put them into GENERATED_HEADER_FILES, as they obviously cannot be
found in a pre-synced source dir. instead, let the injection code itself
add them to INJECTED_HEADER_FILES.
Task-number: QTBUG-67813
Change-Id: Id2a7c565b14fcba8aba9d1dd8b1dd39c586d0d91
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
these are actually redundant with INJECTIONS.
Change-Id: I0a71930401e00d30c9898b4d958de5e89c496d18
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
RCC generates code that registers resources automatically on program
startup via global constructors. When linking statically and nothing
references the symbols in the .o file compiled from the RCC generated
code, then the linker will discard the embedded resources and they will
not get initialized. That is why for static linking it is necessary to
explicitly initialize resources using the Q_INIT_RESOURCE macro.
We can avoid the need for the explicit initialization in the context of
plugins that are statically linked into the application. resources.prf
can generate a .cpp file with a helper function that contains all the
Q_INIT_RESOURCE calls for all resources in the plugin. That helper
function in turn is injected into the plugin entry point, which in turn
is guaranteed to be included in the final binary.
Change-Id: If1abf9c85ef92935020af073b989c58c1ae6ca63
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Fixes the default C version used with gcc < 5
Change-Id: I948dece961caed8e6b181e1c6e6b9dc43c46583e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
the 'info' variable was re-used too early. make a new one 'infoargs'
instead.
Task-number: QTBUG-67286
Change-Id: I77881ecbfce338d653358c5e5edac84e1c0c7de3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
In order to be able to build and test a testcase on an iOS device it
needs to be a bundle. So the app_bundle config should only be removed if
the testcase_no_bundle is set. This is already done by testcase.prf.
Task-number: QTBUG-45211
Change-Id: I4f16ea832ccff2a5db5fed0050fa0344b4ac9ad6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The android mkspecs had their own way of doing the same as optimize_size
Change-Id: Id05822df6bdeb8b3aafada2901bd61530c490fe9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
instead of relying on more or less accidental qmake behaviors regarding
the base dir for relative paths (esp. if a file does not exist yet),
make everything explicit. to that effect, clearly define the base tree
(source or build) for every syncqt-generated variable, and write only
in-tree relative paths to the variables. on the receiving end, resolve
the paths as soon as headers.pri was read.
Task-number: QTBUG-67111
Change-Id: I32ae5760fb62ebc650fdb69e46aac786a8141564
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
that way we can create a config.log which is consistent with the end
state even if (some) tests are not executed this time around.
Change-Id: Ia953ede62d6640aab912559f435ceb1f9ec6d9dc
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Remove references to XKB and explain what to do if
pkg-config is missing or unwanted.
Change-Id: I099bf01ff49e1b8f6e822a50f0fe4904965a7a9f
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Some mkspecs do not support c++ strict mode.
We should allow them to build Qt with GNU extenstions.
Change-Id: I0d76cf95355b38953e3475773ec5474c856e1370
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Allow QML modules to request installing QML files on the file system
regardless of whether the QML files are embedded to resources.
Qt Quick Controls need both; external QML files, that are prioritized
over compiled resources, can be left out from the final deployment
package.
The desired setup can be configured as follows:
CONFIG += install_qml_files builtin_resources qtquickcompiler
With this, there is no need to write custom install/copy/qrc rules
for QML files.
Change-Id: I2ff2974b64efaea341b6ebb4c9fc2612497d7a33
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
For "import MyModule", the QML engine looks for a qmldir file in
$eachImportPath/MyModule.
One of the built-in import paths is ":/qt-project.org/imports". This is
meant for static "plugins", where the resources and the plugin are already
inside the binary image.
For dynamic plugins, the qmldir file is what enables the QML engine to
find the plugin in the first place, so it makes no sense to embed it
inside the plugin's resources.
Change-Id: I29f006efb58d91f7e5212c347087535b06e8c637
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
For correct debug/ and release/ suffix substitution and thus avoid
concurrent access to generated files, we have to declare the output
directory variable used by qtquickcompiler.prf in qtdeclarative here and
enable it for substitution.
Change-Id: Id8483daffdf1b9990396c55f7bc0d08a2f65cafd
Task-number: QTBUG-66675
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The change causes a crash when compiling the xkbcommon 3rdparty
library and compile failures (qtimageformats on Android).
This reverts commit a47cb14680.
Task-number: QTBUG-67326
Task-number: QTBUG-67327
Change-Id: I5ddc4eccad699e3eaec535fd6a63d11b0026b42e
Reviewed-by: Sami Nurmenniemi <sami.nurmenniemi@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
This removes the following functions from Qt5CoreMacros:
- qt5_use_modules(...)
Task-number: QTBUG-63519
Change-Id: I59769060a3a93686bf319b558c0ede55755fdb70
Reviewed-by: David Faure <david.faure@kdab.com>
Fixes the default C version used with gcc < 5
Change-Id: I948dece961caed8e6b181e1c6e6b9dc43c46583f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Generated files should be added to RESOURCES with an absolute path.
Task-number: QTBUG-67011
Change-Id: Ief82b576824df9abd0901970f076e30dfe57b7d0
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
When Qt is configured for both debug and release, and frameworks are
enabled, we produce two dynamic libraries inside each framework, eg:
QtCore.framework/QtCore
QtCore.framework/QtCore_debug
When building an executable against these frameworks, we pass -framework
QtCore, and the resulting executable will have its LC_LOAD_DYLIB load
commands pointing to e.g.:
@rpath/QtCore.framework/Versions/5/QtCore
When running the executable, the dynamic loader will load the dynamic
library dependencies based on these load commands.
By setting the DYLD_IMAGE_SUFFIX environment variable at runtime to
'_debug', the dynamic loader will prefer the debug versions of each
library inside the frameworks.
Unfortunately the use of an environment variable to choose debug or
release versions leaves room for mismatches between the executable
and the libraries that are loaded. An executable built in debug
mode will at runtime pick up the release versions of the Qt libraries
unless the DYLD_IMAGE_SUFFIX has also been set to match the build
configuration of the executable.
This results in confusing situations such as building your application
in debug mode, and then stepping into Qt code but not getting any
symbols. Qt Creator has an option to run the application with
DYLD_IMAGE_SUFFIX set, but this is not enabled by default due
to the startup cost of loading the Qt debug libraries.
More critically, it results in tests failing when the tests are using
QTest::ignoreMessage to ignore warnings produced by Qt, and these
calls are ifdefed (correctly) inside QT_NO_DEBUG, as the test
(built in debug mode) will then expect warnings from Qt, but those
warnings are not emittet, as the test is run against the release
version of the Qt libraries.
To mitigate this mismatch, we now link the Qt frameworks using
an explicit suffix, just like we would for no-framework builds
on macOS, for debug and release builds on Windows, and for
normal builds on other Unixes, leaving the dependency chain
for the application predictable:
@rpath/QtCore.framework/Versions/5/QtCore_debug
This also conceptually matches how Xcode builds applications and
frameworks, where it never relies on DYLD_IMAGE_SUFFIX, and instead
uses two separate build directories, one for each configuration.
The change means that Qt Creator will always load the Qt debug
libraries if the application is built in debug mode. For Qt
development this is a good thing, as you expect to be able to
step into Qt code. For our users, the added startup cost can
be mitigated by shipping our binary packages as release-only,
but with separate debug info enabled.
Change-Id: Ib9f1f2dab90ed00b9fb011200e3a69c71955e399
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Some tests are not written to handle running on a retina screen,
resulting in additional test failures when trying to fix a CI test
failure on a local retina-enabled machine.
Change-Id: I0fed33c38792b686ac83abba2bfbc45623382200
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
On Apple OSes, both compilers and linkers are given an absolute path.
For consistency, the same should be done with the C linkers.
The change is also a convenience to the MacPorts project,
which actively discourages ambiguous compiler names.
(https://trac.macports.org/wiki/UsingTheRightCompiler).
Change-Id: Ic1885aed825340696e9fde766788eebf51de3ff6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Change-Id: I7d5f211e2441415134c5905b159b41dc3b2b231b
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is needed to be compatible with latest Qualcomm BSP releases.
This patch also makes it possible to select HW layer via
QT_OPENWFD_CLIENT_ID and QT_OPENWFD_PIPELINE_ID environment variables.
Change-Id: Ie795b21afc61a1de7c1d0b52cdb30a754e3f8266
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
Reviewed-by: Timo Aarnipuro <timo.aarnipuro@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit 00f693d3e5046999270c92731e34a3e7fcd01c6b)
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
... and make use of it.
it's a logical continuation of the 'arch' term, and will be used also in
qt3d's configure.
Started-by: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: I940917d6763842499b18fffd1514c96889a0cc63
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
with 40e87491 merged, 'QMAKE_CXXFLAGS' variable in
'win32-g++' toolchain became defined via 'QMAKE_CFLAGS'.
the similar can be found in 'win32-clang-msvc' and
'win32-icc' toolchains too.
this works for now, because such definitions just duplicates code
from includes, like 'gcc-base.conf', 'msvc-desktop.conf', etc.
but it would became broken, if changes would be applied to
'QMAKE_CXXFLAGS' definitions in that includes, prior
to the redefinitions in 'win32-*/qmake.conf' toolchains.
thus 'QMAKE_CXXFLAGS' definitions in 'win32-*/qmake.conf' toolchains
should not depend on 'QMAKE_CFLAGS' and be done explicitly.
in order to apply this change correctly to 'win32-icc' toolchain,
its 'QMAKE_CFLAGS' variable should become dependent on definitions
in the includes, similar to 'win32-clang-msvc' and
'win32-msvc' toolchains.
Change-Id: I5e820e44a769a590ba63f70dcb3a115311093311
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
contains() interprets the regexp as being implicitly
anchored, so the leading part of the path needs to be
explicitly matched.
Change-Id: I1efa07dc99bb2db1717d2a66621899e23c144164
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
$$RCC_DIR can be absolute, so simple concatenation with $$OUT_PWD is
bound to fail.
Change-Id: Ibd80c49656c0e03b8a86ebca851af106cced08fb
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
in non-prefix configs, one has to differentiate between the module's own
build dir and qtbase's build dir, because the forwarding headers are
placed in -outdir under include/, while the actual headers end up in the
real build dir under src/.
Change-Id: I1d8ac904556b354bd113995316ba11dd6560a70d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Right now we are using the C++ compiler here, which relies on
the compilers automatically switching mode. This behavior is also
deprecated in newer clang versions and block clang developer
builds.
Task-number: QTBUG-64822
Done-with: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: I4d3c00ac528a45934c85777f42d243d0fe367c92
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This commit introduces minimal support for instrumentation within Qt.
Currently, only LTTNG/Linux and ETW/Windows are supported.
Change-Id: I59b48cf83acf5532a998bb493e6379e9177e14c8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
'win32-icc' toolchain:
- remove duplicated angle/vulkan includes.
'win32-g++' toolchain:
- place angle/vulkan includes before the unrelated compiler-related
variable re-definitions, similarly to the 'win32-clang-msvc',
'win32-icc', and 'win32-msvc' mkspecs.
Change-Id: Ie04bc9fb1d51ec0366b42713439f680e51214bbc
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The PRODUCT_BUNDLE_IDENTIFIER property was not defined in the Xcode
project file and therefore the build would fail.
This fixes a regression introduced by 0749ba2c5e.
Task-number: QTBUG-65673
Change-Id: I8089b36d86588223ec34859af7388c99a3574d8b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Build systems such as Meson heavily rely on pkg-config to get build
flags.
-DQT_{module}_LIB isn't exported in .pc files which makes Meson unable
to build some codes out of the box.
Change-Id: I806998f19f815e05a47b60129977e52587b38d47
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
mingw-w64 toolchain:
- remove 'QMAKE_CFLAGS_AESNI' and 'QMAKE_CFLAGS_SHANI' definitions,
which are already set in 'gcc-base.conf' toolchain; this is
a continuation of 77347a36 relating variables, introduced in 5.10,
- remove 'gcc-base.conf' duplicate inclusion, left after eef2d1af
was merged into 5.10.
Change-Id: I328def916ccfb93c3f6b8336eb8801defbac37ae
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The Embedded Android build (Boot to Qt Android injection) is defined by
having both Q_OS_ANDROID and Q_OS_ANDROID_EMBEDDED flags defined,
as well as having Qt config android-embedded.
This commit enables the possibility to build embedded Android builds.
(i.e. Qt build for Android baselayer only, without JNI)
Change-Id: I8406e959fdf1c8d9efebbbe53f1a391fa25f336a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
such a project structure violates the assumption that the referenced
resources are specified relative to the sub-project root, so we must
resolve them to absolute paths manually.
Task-number: QTBUG-65753
Change-Id: I8bcd5c6e7d7c6a713e5fcd3668be7d2f23169501
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When QFile::open is called with the NewOnly flag, the call will
fail if the file already exists. As usual, if the file does not exist,
it will be created. Like QTemporaryFile, there is a guarantee from
the operating system that you are not accidentally creating a new file
on top of an older file. When QFile::open is called with the
ExistingOnly flag, the call will fail if the file does not exist. The
ExistingOnly flag only provides new functionality when used with the
WriteOnly flag. For ReadOnly it provides no change in functionality,
as ReadOnly by itself already never creates.
Task-number: QTBUG-52244
Change-Id: I8e3206728f245f95172c225bf297023fb078fc6d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
mingw-w64 toolchain:
- add missing compiler definitions, similar to
'msvc-desktop.conf' toolchain,
- describe the reasons of missing compiler definitions, available in
'msvc-desktop.conf' toolchain,
- add missing 'QMAKE_CXXFLAGS' and 'QMAKE_CXXFLAGS_WARN_ON' variables,
similar to 'msvc-desktop.conf' toolchain.
ICC on Windows toolchain:
- add 'QMAKE_CFLAGS_OPTIMIZE_FULL' variable, similar to 'gcc-base.conf'
toolchain, though left it unused for now,
- add missing flags to 'QMAKE_CFLAGS' variable, similar to
'msvc-desktop.conf' toolchain,
- update deprecated 'Qwd' flag with 'Qdiag-disable',
- use 'QMAKE_CFLAGS_OPTIMIZE_DEBUG' variable instead of '-Od' flag,
similar to 'gcc-base.conf' toolchain (ICC implies '-O2' optimization
level by default, while MSVC implies '-Od'),
- add 'QMAKE_CFLAGS_UTF8_SOURCE' variable, similar to
'msvc-version.conf' toolchain; use a workaround to initialize it,
until '-utf-8' flag would be supported by ICC on Windows,
- update deprecated '-Qstd=c++1z' flag with '-Qstd=c++17',
MSVC toolchain:
- remove 'incremental' from MSVC 'CONFIG' variable, since it has
relevance only for the Unix generator,
- add 'QMAKE_CFLAGS_OPTIMIZE_DEBUG' variable, used in ICC for Windows
toolchain,
- add empty 'QMAKE_LIBS' variable, similar to 'win32-g++' toolchain,
- add 'uuid.lib' library to 'QMAKE_LIBS_GUI' variable, similar to
'win32-g++' toolchain,
- add C++14 and C++17 language support flags, though left them disabled
for now, similar to 'win32-icc' toolchain.
Change-Id: Ideef62d0422674184836faa655bfc5d09a5f612f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
otherwise the project would need to clear QT despite using
qtHaveModule() in requires() (or REQUIRES=).
Task-number: QTBUG-65106
Change-Id: I568202214c8eafcdbe2d0e253b18f0e171293aff
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Old header.LGPL21 header was used at some files. Replase those with
new header.LGPL one
Remove old header.LGPL21
Task-number: QTBUG-57147
Change-Id: I650e39024ed4876bba27e954c7d61fdb025b46ef
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This ensures that the same set of variables can be successfully replaced
in both the Makefile and Xcode generators. It also switches the default
templates to use the Xcode-style ${var} syntax instead of the @var@
syntax for better Info.plist compatibility across generators.
Change-Id: Iff330bafd152773aafac9143c4a34e34f92f0ce6
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>
Common changes to mingw-w64, ICC on Windows, and MSVC toolchains:
- set similar order of variables and its splitting into sections,
- set similar order of flags in variables and the way they are set.
mingw-w64 toolchain:
- move 'gcc-base.conf' include before setting Windows specific
flags, similar to include 'msvc-desktop.conf' in ICC on Windows
toolchain; this leads to consistency with other toolchains
and allows to safely override common GCC variables with Windows
specific ones, when needed,
- move 'QMAKE_EXT_OBJ' and 'QMAKE_EXT_RES' variables to the linker
flags section, according to its purpose.
MSVC toolchain:
- set flags order in 'CONFIG' variable, similar to mingw-w64 toolchain.
Change-Id: I417cc8f7959c669dd504f2c5c11eb879a7989bd4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
mingw-w64 toolchain:
- remove 'QMAKE_CXXFLAGS_THREAD' variable definition, since
'QMAKE_CFLAGS_THREAD' variable not set for mingw-w64 toolchain.
ICC on Windows toolchain:
- remove 'QMAKE_LFLAGS', 'QMAKE_LFLAGS_RELEASE',
'QMAKE_LFLAGS_RELEASE_WITH_DEBUGINFO' and 'QMAKE_LFLAGS_DEBUG'
definitions, since they're properly set in 'msvc-desktop.conf',
- remove 'DSP_EXTENSION' variable, which doesn't occur anywhere else
within QtBase; its most recent search results relate to
Visual Studio 6.0 and Intel Fortran.
Change-Id: I2ce5c2c9e9ca2c09c1acfcf8c60381d318e8e380
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
If the linker supports it, add the gdb index to the debug symbols, which
makes loading gdb on Qt libraries much faster.
Change-Id: I2ed201c22913b97ac2efaefb5e31636e795ae102
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This works around the inability to build iOS apps for a "generic"
simulator by explicitly setting the Xcode build setting
ENABLE_ONLY_ACTIVE_RESOURCES to NO in order to ensure that all variants
of assets in an asset catalog are built when targeting iOS simulator
devices. Otherwise, we will simply build for whatever the first
simulator in the list happens to be. If the application is then deployed
to a different simulator, some of the assets needed for that device
variant may be missing.
This "helps" QTCREATORBUG-19447 but is not a workaround since this fix
is necessary for command line builds anyways, even though it's unlikely
to crop up in practice there, since one would have to manually deploy
the built application bundle to the simulator using simctl rather than
going through Xcode (which would rebuild for the appropriate device).
Change-Id: Ia41c48dcc715fe79a2c50db66a0ca7a1fea159c2
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
... instead of only toolchain.prf.
the license check could go haywire, and everything else that file does
is meaningless in configure context anyway.
Task-number: QTBUG-63452
Change-Id: I5e31c87fe717fda40978c0317556070637e537e2
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
otherwise test de-duplication between modules doesn't work.
Change-Id: I2c6222d853108df223758aa8907dc8d004efd87f
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
especially during debugging, it is often necessary to re-run only one
(or a few) tests, where -recheck-all would be wasteful.
Task-number: QTBUG-64059
Change-Id: I9410894dec4289ff832d7f75e04f9b60fe76c57c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Enable xcb QPA plugin when XQuartz is available. This is done
in a single build, alongside the Cocoa version.
We delegate part of the configuration stage to pkg-config, so
this becomes a requirement. Ensure that
PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig:/opt/X11/share/pkgconfig
is in your environment, or pkg-config is properly set up.
Tested with the following configure options:
configure \
-pkg-config \
-fontconfig -system-freetype \
-system-xcb -xkb -no-opengl \
-qt-xkbcommon -qt-xkbcommon-x11
Change-Id: I2eb5a0491172368afc4c629c540cbef08580348d
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
it could be somewhat surprising that specifying variant-specific libs
would not clear the common libs, so do that. of course, the default
for the common libs could theoretically contain common deps of the
variant-specific libs, in which case clearing them would be surprising
in turn - luckily, we have no such case.
Change-Id: Ifca08b9e1949c6a0cefed6931ade4021927d7c90
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
