while it's mildly insane that we auto-generate install targets to start
with, we can at least refrain from doing so if there is one already.
as it happens, this removes the need for excluding the qt build
explicitly.
Task-number: QTBUG-38452
Change-Id: I74d5df447fba525fa79896c9be2c71d82bc2c6ce
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This was originally enabled in the mkspecs for 64-bit QNX 7.0.0
but that broke when the qtConfig change was made. It looks like
qtConfig shouldn't be used in the platform mkspecs. I suspect
the stack-protector changes were left out of the 32-bit mkspecs
so that 6.6.0 builds wouldn't be affected.
Ignore the stack-protector/stack-protector-all possibility since
it isn't possible to access it without a command line option.
Specifying both options doesn't even make sense since
stack-protector-all encompasses stack-protector.
For now, leave out command line control of this feature.
Task-number: QTBUG-59644
Change-Id: I99323216be5b592dd2c3bef6d22da195764a6e65
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The -Xarch option is not supported by ccache, so unless we need to
distinguish precompiled headers for multiple architectures it's better
to not pass it.
Change-Id: Iae02d37f7a89aedebecedff7290f88d2de1ca362
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Do not pass /Za to MSVC to generate moc_predefs.h, because this option
is incompatible with compiler options like /fp:fast that may be
user-specified.
The /Za option added, because moc failed parsing header files that
contain MSVC extensions. Moc was fixed in 94a2aec0, and we can safely
remove the /Za option.
Task-number: QTBUG-58391
Change-Id: I9791224b1773d0f81d2bbb7915787a7c5e68430c
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
there isn't really a point in doing strict shadow builds of them, and
it complicates stand-alone building of sub-projects (because it points
below the build root).
Task-number: QTBUG-58372
Change-Id: Ia3bde3826baac44749b27452fd4aeb9491ecb94e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
... and rename those determined by toolchain.prf to QMAKE_* (this was
already the case for the newly introduced msvc and icc variables).
this restores the ability for user projects to query the toolchain qt
itself was built with, which is necessary for compatibility checks.
in fact, we may do such validation in toolchain.prf itself at a later
point.
Change-Id: I35f4c393c5e4e0fe987c0844714b7a8f8687c24e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We need to actually run the linker, otherwise clang will just
run the preprocessing step as we asked for. We build as a shared
library to not have to provide a main() function.
Change-Id: Ied34757bb5c43a862bf2d9778340c497b93d572f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The flag makes the build fail for UWP as well as desktop Windows . It
will trigger a compile error as soon as UWP API is used, which happens
in qtbase for desktop in the direct2d backend, but it is also used for
other Qt modules, so we decided to disable the flag for now.
This patch partly reverts b7d76e533c
Task-number: QTBUG-61239
Change-Id: I0cc630f4c09c52f0c116f4a7b95a44c3a55e0be3
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
It seems this change is preventing us to integrate qt5.git in '5.9'
This reverts commit c3030d7163.
Task-number: QTBUG-61204
Change-Id: Id98afaa23be0a8dd6f2c54a899f46542c65436aa
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
That's not the same as -Za.
Change-Id: Ica9894dc9b5e48278fd4fffd14bb316b687abffe
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
this actually just makes the code more straight-forward.
amends f8607045c.
Task-number: QTBUG-60936
Change-Id: Iaa05b474206cf29352f9bba516936ff30b90a778
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
the entry's libs field is supposed to be a single pre-quoted string.
that implies that the libs and libpaths need to be joined first.
amends 7e298e2f.
Task-number: QTBUG-60925
Change-Id: Id85b2784e3c081b3ff8eb9ee2216976691f8580d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
adding shared install paths via QMAKE_LFLAGS in the spec has the tiny
side effect that they are searched _first_, which is generally a really
bad idea - they should be _last_.
for that purpose, introduce QMAKE_RPATHLINKDIR_POST, and migrate all
specs to use it.
QMAKE_RPATHDIR_POST is added for consistency, but not actually used.
Task-number: QTBUG-59457
Change-Id: Iac6cda5e9111ef8cca454a69861fe8408bb40589
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
adding shared install paths to QMAKE_{INCDIR,LIBDIR} in the spec has the
tiny side effect that they are searched _first_, which is generally a
really bad idea - they should be _last_.
for that purpose, make QMAKE_{INCDIR,LIBDIR}_POST live up to their names
(i.e., search them actually last) and migrate all affected specs to use
them.
Task-number: QTBUG-40825
Change-Id: Ie0de81c3cc49e193186d2fedd7d6c77590c8ef79
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Because we obviously don't support Microsoft's extensions in C++. This
is required because some MS headers have code that isn't proper C++,
like iso646.h:
#if !defined(__cplusplus) || defined(_MSC_EXTENSIONS)
#define and &&
Do not pass /Za to MSVC to generate moc_predefs.h, because this option
is incompatible with compiler options like /fp:fast that may be
user-specified.
This reverts commit e1a70ce4 and re-fixes the issue similarly to commit
d72ac3f3.
Task-number: QTBUG-58391
Change-Id: I5c0143283afed09f98200806c87259c039c00ae1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
As Qt applications using OpenGL are linked against these libs, merging
them into QtANGLE by default (780105f906)
was a binary incompatible change. This change restores the default
behavior to the one before given change.
If the user wants the libraries to be merged, he can pass
combined-angle-lib to configure.
Task-number: QTBUG-60373
Change-Id: Iedbd3f2ce9284fdde924cfae8d915d6d5fef00db
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
prefix it to the purpose field. this makes the presentation more
consistent with the graphical tool, and avoids the need to be redundant
in the description.
Change-Id: Iea58885637e0518aa1ec2f69ff05090b7e1e77a9
Reviewed-by: Stephan Binner <stephan.binner@basyskom.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
As the directory installation command also works with files as a source
we can unify the external commands, resulting in simpler command lines.
Change-Id: I65013626eedbdb3ce1c77ed230d46edd1603b986
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
VS 2017 still uses vclibs version 14/140 and it also strictly requires
the vclibs' publisher to be set in the manifest. As we only support VS
2015 and 2017 the condition for adding additional vclib dependency
information can be dropped.
Change-Id: I813a9ad976339e347fd8d9283d92282e86b2791b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Use the new qmake install command to copy files around, in order to
avoid the '+' trap of the Windows copy command.
Task-number: QTBUG-60214
Change-Id: I7f588dbbfcdd89b7e98dbef7757944ca856815aa
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Adds default off configure flag to use compiler optimizations
for size instead of the default speed/size trade-off.
Change-Id: I36702064ef2cc743d2d03a386adf5cefd5371b6e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
the options are mutually exclusive, with the last one winning.
Task-number: QTBUG-60382
Change-Id: Ie6d888ac8be6b22b204fcad93c184477baa38965
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
delaying the logging setup until the cache use is determined (which
depends on xspec determination) causes too much trouble.
as already explained in 7ac15ab0f, there is a bit of a gray area when
exactly the log should be cleared anyway.
a more complete solution would cache the tests' output along with the
results and re-log it (with an appropriate marker) upon re-use.
Task-number: QTBUG-59565
Change-Id: I17d457598d885bceafd6505cad5ff074c4ace502
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
They have not been tested with Qt 5, not even once to make sure
that the mkspec passes the sanity check.
This removes for OSes:
HP-UX (running on PA-RISC -- Itanium still supported)
SGI IRIX
SCO Unix
Tru64 Unix
Unixware
And compilers:
IBM xlC (Visual Age C++)
HP aCC compiler (PA-RISC and Itanium)
PGCC, cxx and kcc on Linux
There were a couple more OSes detected in the configure script that were
lacking even the mkspec. Those have also been removed.
Of those, only hpuxi-acc and aix-xlc have been tested in the last 9
years, though only with Qt 4 and never tried with C++11 support. IRIX
was last tested over 10 years ago and PA-RISC is definitely not
supported due to its lack of atomic operations.
Support for HP-UXi and AIX is now only possible with GCC (assuming GCC
supports those). Support files for Oracle's Sun Studio compiler are left
behind, but its state is unknown.
Change-Id: I7814054a102a407d876ffffd14b69c796b97c972
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The module might add QT_RESTRICTED_CAST_FROM_ASCII to DEFINES to
be able to use string literals under the assumption they are UTF8
without warnings from QT_ASCII_CAST_WARN, but this conflicts with
QT_NO_CAST_FROM_ASCII which is added for the headersclean build
step.
Change-Id: Ic1d7b5415350477d751a6c15219d4f8feb816a3c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This change restores usability of Qt with older versions of CMake which
do not provide a language feature used in the implementation of the new
Qt5::<ModuleName>Private targets.
Task-number: QTBUG-60229
Change-Id: I6a6a1b09be3edca200692250bb8f0d7f6a1b8f7a
Reviewed-by: Stephen Kelly <steveire@gmail.com>
While a previous commit added the logic for handling arm from a qmake
perspective, the responsible mkspec was forgotten.
Change-Id: I5f36d411f2d2c22d8b048e0931da50d911e7e1b4
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Creating a precompiled header exclusively for a one- or two-file module
is wasteful. The time that it takes to build the precompiled source is
on the same order as a regular compilation, so enabling precompiled
headers for those modules just makes the build slower.
Also make it possible to override the precompiled header by just setting
PRECOMPILED_HEADER to empty.
Change-Id: I0e1a09998253489388abfffd14b5f221288c4826
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Let's not allow any new code that uses non-conforming syntaxes. With
GCC and like, we already use -std=c++11 instead of -std=gnu++11 for that
very reason.
Change-Id: I4a7dc1fe14154695b968fffd14aba9f8cea69c47
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The original commit only added support for GCC and Clang, but not ICC.
Amends 73331eeb
Change-Id: Id7638cf1b538edb1008fb3aa10754c1f517a994f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Otherwise, in separate_debug_info.prf, we try to process the original
target, which is not what we actually build.
Task-number: QTBUG-59779
Change-Id: I2b2d2e7b5f87041cc51075da7c3a5b690f94f1f3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Neither the Intel compiler nor Visual C++ have a dedicated switch to
enable F16C support, like GCC and Clang do. So we used the AVX switch
for that in commit 8241d51f70, as it was
the closest, lowest denominator. That was incorrect and insufficient.
The Intel compiler silently miscompiles the intrinsics with -xAVX,
making calls to out-of-line functions like _mm_cvtps_ph, which don't
exist. So we actually have to use AVX2 support to generate correct code.
That might be a problem later, since Ivy Bridge supports F16C but not
AVX2.
Visual C++ is able to generate F16C code with just -arch:AVX.
Either way, since there's no dedicated command-line switch, there's also
no dedicated preprocessor macro. We're using __AVX2__ for both
compilers, as that's a sufficient condition to indicate a processor that
supports F16C.
Change-Id: I27b55fdf514247549455fffd14b205b8d8b86da7
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The .pro file requires the QMAKE_CFLAGS_F16C to be set to something. So
set it to AVX, as the instructions require the VEX prefix anyway (ICC
has no dedicated option for just F16C).
Change-Id: I27b55fdf514247549455fffd14b171940afd35a2
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The configure-time detection (cxx11default) isn't enough if the compiler
can be changed. This is especially necessary if Qt is compiled with a
compiler that defaults to >= C++11 (e.g., GCC 6) and then the user
selects a compiler another compiler (e.g., Clang) via -spec option. In
that case, we'd miss adding the -std=c++11 or -std=gnu++11 option to the
command-line, causing the compilation to fail.
As a nice side-effect, even moc without moc_predefs.h will now get the
__cplusplus setting.
Task-number: QTBUG-58321
Change-Id: I74966ed02f674a7295f8fffd14a8be35da9640e1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
The compiler is mostly GCC in disguise, but the libraries are not. Since
the toolchain is not open, it's difficult to fix issues in it.
Task-number: QTBUG-59671
Task-number: QTBUG-59672
Change-Id: Id92f4a61915b49ddaee6fffd14aea2639153f073
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
the borrowing of headers always happens from "proper" modules which are
actually built as frameworks if so requested. that means that even
though the borrowing module itself never is a framework, it needs a
framework path and include paths that point into frameworks.
amends 20c7ab44.
Change-Id: Ic582060dd179cc592e9be7792ff02cebdfabd772
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
