the callback is specific to qtbase/configure.json, so it belongs into
qtbase/configure.pri.
amends d90db0f136.
Change-Id: I905f985e2d3d2e42c4587cbacdea8dc3eb09a5be
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
As the comment says, Haswell is a nice divider and is a good
optimization target.
I'm using -march=core-avx2 instead of -march=haswell because the latter
form was only added to GCC 4.9 but we still support 4.7 and that has
support for AVX2.
This commit changes the AVX2-optimized code in QtGui to Haswell-
optimized instead. That means, for example, that qdrawhelper_avx2.cpp
can now use the FMA instructions.
Change-Id: If025d476890745368955fffd153129c1716ba006
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Tell qtwaylandscanner to export the symbols when we're building a
module. This is done by specifying the include directory on the
qtwaylandscanner command line.
Task-number: QTBUG-68773
Change-Id: Ib575222261831ab01eb43e6c7caefb07e314492b
Reviewed-by: Johan Helsing <johan.helsing@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Generated headers can now be installed using inject_headers and private_headers
instead.
Change-Id: I51d98e2e05d12aa9f6ab09f8ccb12b81a0c0cd6f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
"AVX512MIC" (Many Integrated Cores) is the set of AVX-512 features found
on the Intel Xeon Phi coprocessors (codename "Knights Landing"), which
is an unlikely architecture for Qt to run on.
The two profiles with VL came from study of early GCC code and are no
longer applicable. GCC source code now shows both VBMI and IFMA as part
of the -march=cannonlake feature set.
Change-Id: Iff4151c519c144d580c4fffd153a0f268919fe2c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This is a partial revert of commit:6c5d227da1709eb81968823f38a133747c0e95b0
All credits to Martin Afanasjew <martin@afanasjew.de> for the original patch.
Change-Id: Ib66303505888c821fc43eca213b956ce76acbbfa
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The macOS framework build of Qt copies headers to each
framework instead of a centralized include location.
Update the .pc file generator to match this behavior.
Add two include paths to the .pc files:
-Ipath/to/lib/foo.framework/Headers
This makes #include <FooHeader> work.
-Fpath/to/lib
This makes #include <Foo/FooHeader> work.
Task-number: QTBUG-35256
Change-Id: I013ce161c904fe6b7bbb03e33c163d32fdda0647
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
If CONFIG option no_include_pwd is set, moc does not add the build
directory to its include path. The path to the generated
moc_predefs.h file is by default relative though, resulting in
moc warnings:
Warning: Failed to resolve include "debug/moc_predefs.h" for moc file xxx myheader.h
Fix this by always making the path to moc_predefs.h absolute.
Task-number: QTBUG-69087
Change-Id: I8ef79c8340f9ebd6b0bba15e026d65ef3c088535
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
By using -march= instead of -x, we turn on some other processor features
too. This was already the case for AVX2, which enabled all Haswell
features (notably FMA, BMI and BMI2).
Change-Id: If025d476890745368955fffd153126fc9eafc5d6
Reviewed-by: Alexander Shevchenko <sav_ix@ukr.net>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
linux-icc and macx-icc toolchains contain a significant amount of code
which can be merged to a common configuration file.
as a side effect, such merge resulted in reduction a parts of
linux-icc and macx-icc toolchains to the common view.
Change-Id: I37d110734eeeb9bd61ca0aa942de380ac8e75f1c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This allows distinguishing between these tools and tools for the host,
when cross compiling.
While mac tools normally only are available on macOS, there are third
party efforts to port them to other platforms. In these cases, it
might be useful to use a prefix (either some sort of triplet prefix,
or an absolute path) to distinguish between the host build platform
compilers/tools and the ones for the cross target.
The use of this variable matches the one used in a lot of other
mkspecs, and shouldn't cause any issues for those who aren't setting
it.
Change-Id: Iaeba571d955ea79ed1249989fcc525eb1eaf1f5c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Do allow people to build from git using the Qt License Agreement 4.0.
The license agreement text is the same as in the installers, except
that some Unicode characters got normalized to their ASCII variants,
and things have been properly wrapped.
[ChangeLog][Licensing] The commercial preview license in the git
checkout has been replaced by the Qt License Agreement 4.0 text.
This makes it explicit that commercial customers of The Qt Company
can use the git version under commercial terms. However, support
is (still) only provided for builds from released branches of Qt.
Task-number: QTBUG-52222
Change-Id: I9e99b68e236a09610b798ba7a841e5a9d1ce6898
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Perfectly valid C++11 code trying to default-initialize an object with
{} is being warned. GCC 5 and up only warn if you initialize some fields
and not others.
qcborvalue.h:68:25: error: missing initializer for member 'QCborError::c' [-Werror=missing-field-initializers]
QCborError error = {};
^
Task-number: QTBUG-68889
Change-Id: I6efb28c3145047559ec0fffd1538577de250e283
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
as evidenced by things actually still working despite qmake_use.prf
not processing *_CFLAGS, this is not relevant for any makeSpec sources
any more, and was never relevant for other non-pkgConfig sources to
start with. localizing the code cleans things up.
as a side effect, configure won't emit a notice for dropped flags any
more, but will only log them to config.log. i think that makes sense,
as for the average user that would be only noise anyway.
Change-Id: Iaffde6474b786f5cbcbeac881850792563b74495
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
the json format uses single strings for library sources, as that leads
to less noisy source text. however, this implies the need for de-quoting
and subsequent re-quoting whenever the values are processed. so change
the internal representation to regular qmake string lists as the first
thing when processing the lib source, and re-quote only when outputting
the values.
CFLAGS are excluded, because we'll deal with them differently.
Change-Id: I4ab43d98085ea9f6601fd21ac2afb5bce4f7e2a9
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
wayland-scanner.prf uses it as a trigger, so this is needed to make dynamic
non-prefix builds work.
amends 427e5d61b7.
Task-number: QTBUG-68773
Change-Id: Ia7d3bc39cb2b0f225e827f64eb17d061d594b265
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
We need -Zc:__cplusplus in order to enable the __cplusplus macro having
the correct value. This causes configure to now print:
Checking for C++14 support... yes
Checking for C++1z support... yes
and
Using C++ standard ..................... C++1z
Change-Id: I5d0ee9389a794d80983efffd152c95a4d9d8adbc
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The new build system in Xcode 10 requires outputs from shell script
to be explicitly declared if they are used by subsequent build phases,
otherwise the build system may attempt to search for the file before
it has been generated, causing the build to fail.
The build phase we use for Qt preprocessing (moc, rcc, etc), does not
list these output files, so we need to disable the new build system
for now.
Change-Id: I7404c19021f57489e985bd1203ad09ce9b83b090
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
otherwise, names like "core" are too likely to clash.
note that the directories (which contain configure files) still need to
have unique names within one repository. that's unlikely to be a
problem.
Task-number: QTBUG-68385
Change-Id: I01c60479a6a45494ba60e798ceada231d8870556
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
making the dependencies on tools/ optional was meant to maximize build
parallelization, but it's just too fragile, as nobody ever remembers (or
even knows) about having to add the flags when necessary.
Task-number: QTBUG-68478
Change-Id: I85c0b65d5a63109aedc24bc17eaaaf46b777b634
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
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>
