Commit Graph

26 Commits

Author SHA1 Message Date
Oswald Buddenhagen
c55bdc271f don't apply warning options to host builds
the host compiler's version is not determined, so we cannot make any
assumptions about its capabilities.

Task-number: QTBUG-53017
Change-Id: I939fd7402b5daac73f2195b9d8763b9008bc7ea4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Rolf Eike Beer <eb@emlix.com>
2016-04-29 09:58:42 +00:00
Thiago Macieira
f494da8895 Clang 3.8 is clean of warnings
Change-Id: Ibc83b9f7e3bc4962ae35ffff1425c8e686579e15
Reviewed-by: Jake Petroules <jake.petroules@theqtcompany.com>
2016-04-13 22:08:12 +00:00
Marc Mutz
992e762f66 qt_common.prf: when looking for GCC >= 4.6, match GCC 6+, too
Change-Id: Ia04690f62faa214fb91dffc758e253b5a64e5648
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
2016-03-05 09:58:30 +00:00
Thiago Macieira
09aeda21b9 Update the list of compilers we are free of warnings with
I've tested with Clang 3.7 and ICC 16 on Linux, XCode 6.4 on OS X for OS
X (not iOS).

Change-Id: Ib306f8f647014b399b87ffff13f1f4291d801a20
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2015-09-22 06:21:20 +00:00
Thiago Macieira
4684c1afe5 Add detection of C++14 and C++1z compiler features
[ChangeLog][General Improvements] Qt's buildsystem now detects whether
the compiler supports C++14 and experimental support for C++1z. If the
compiler supports it, then Qt is automatically compiled using that
support.
\
This does not apply to user applications built using qmake: those are
still built with C++11 support only. To enable support for C++14 in your
application, add to your .pro file: CONFIG += c++14 (similarly for
C++1z).

Change-Id: Ib056b47dde3341ef9a52ffff13ef1f5d01c42596
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
2015-09-05 23:05:40 +00:00
Thiago Macieira
ff44440651 Make CONFIG += c++11 by default not disable GNU extensions
Prefer -std=gnu++11 unless strict_c++11 is defined. You can enable
strict C++11/C++14 mode by using
   CONFIG += strict_c++

That is enabled for Qt's own code, so we we don't accidentally use GNU
extensions in portable code.

There's no support for strict C++98 mode (that is, the -ansi option).

[ChangeLog][qmake] By default, GNU extensions are now enabled with
Clang, GCC and ICC even in C++11 and C++14 modes. To disable the GNU
extensions, add to your .pro file: CONFIG += strict_c++.

Change-Id: Ib056b47dde3341ef9a52ffff13ef14de2169bef5
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
2015-07-17 17:36:27 +00:00
Thiago Macieira
d0813bfa6a Update the list of compilers we are free of warnings with
I've tested with GCC 5, Clang 3.5 and 3.6 on Linux.

Change-Id: Ia0aac2f09e9245339951ffff13c87198f2e8aa35
Reviewed-by: Sérgio Martins <sergio.martins@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2015-07-17 00:50:04 +00:00
Kai Koehne
661f604fbc Let MSVC treat warnings as errors
Treat warnings printed by MSVC 2012, 2013 as
errors in the modules that declare themselves
warning_clean (for developer builds).

Change-Id: I55fb3bde460e13cfdbd6f59634e3b5335b2dd715
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
2015-05-18 13:45:33 +00:00
Oswald Buddenhagen
a64cfadaff make the installed meta files play nicely with sysroots
pkg-config .pc files use the raw target paths (and pkg-config patches up
-I and -L flags on the fly), so these files were actually already fine.

libtool .la files use the magic prefix = to denote the sysroot.
this works only with libtool 2.4+ (sept 2010).

qmake .prl files have no built-in sysrootification magic, but as they are
read by qmake, it's possible to put property references into them. this
makes them relocatable, both inside and outside sysroots.

Change-Id: I97236ac81e7aba4e4771d14a44cbf59144cc2d3e
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
2015-02-05 14:26:44 +00:00
Thiago Macieira
a31b75b766 Use the GCC and Clang __builtin_bswap intrinsics in qbswap
Glibc will use the intrinsics for 32- and 64-bit, but didn't for 16-bit
(probably because GCC didn't document it until version 4.8), so this
commit will make us access the intrinsics directly the intrisincs for
all type sizes.

Additionally, this will get us access to the compiler intrisics even
without Glibc, such as when building against uclibc or Bionic.

Another benefit is that both Clang and ICC will use the MOVBE
instruction on Atom and Haswell architectures.

Change-Id: I39d1891f479887d719d69ebe4ac92ac9bfeda8af
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
2014-12-20 01:41:00 +01:00
Thiago Macieira
6336ae831d Enable the latest versions of GCC, Clang and ICC with -Werror
Tested with GCC 4.9, Clang from XCode 5.1 and ICC 15 beta.

Clang 3.5 (pre-release) cannot compile qtdeclarative yet with -Werror
due to invalid C++ code there that calls member functions on null
pointers.

Change-Id: Ic2845371a1899716985bc0813dfb820fa418e207
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2014-10-31 19:18:01 +01:00
Simon Hausmann
9b3b33b110 Fix linking warnings on OS X with qmlimportscanner
The linker complains that some symbols were compiled with different visibility
settings when linking host_build tools such as the import scanner. As it turns
out, we do CONFIG += hide_symbols for static libraries (such as bootstrap or
qmldevtools) but naturally not for the final program source code. It appears
symbol visibility is not of importance for static libraries in host builds (as
opposed to static libraries later linked into shared libraries), therefore this
patch removes that.

Change-Id: I237a2d8669374eb059dc91b5378f6e3ec93d67a6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2014-05-23 08:39:57 +02:00
Oswald Buddenhagen
eaefbe36e8 snuff -L/-I with system paths when installing meta files
Task-number: QTBUG-37963
Change-Id: I8e268387f9dc33d7fab76395301b1396ca0445ff
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Davide Pesavento <davidepesa@gmail.com>
2014-04-15 17:37:50 +02:00
Oswald Buddenhagen
a33afed198 de-duplicate setup of libdir replacement in prl files
Change-Id: Ia93fa02d9e63597d3347fee3aaf2aca65e7cc83a
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Davide Pesavento <davidepesa@gmail.com>
2014-04-15 17:37:47 +02:00
Oswald Buddenhagen
5915fb969f purge -separate-debug-info=nocopy
clearly, this was a poor man's implementation of -force-debug-info.

Change-Id: Ib5c7e390bd0e3a6912af8c4027074a114ed33f8a
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2014-03-20 10:36:34 +01:00
Thiago Macieira
1949a8c003 Let Apple Clang 5.0 also have -Werror support
Change-Id: I3abc83617c8f3426e4f5920052281fe13e4e3edc
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
2014-01-14 23:32:21 +01:00
Thiago Macieira
81157d2374 Use the QMAKE_CXXFLAGS_WARN_ON variable for setting -Werror
This would mean we don't pass -Werror when under CONFIG += warn_off.
However, that's not the main goal. The main goal of this change is to
have -Werror appear *after* -Wall -Wextra.

With some compilers, like Clang, this is necessary to have the
-Wno-error=foo options work properly. For example, if the -Wfoo
warning gets enabled by -Wall, Clang will treat it as an error if the
arguments appear in the following order:
   -Werror -Wno-error=foo -Wall

But not if they appear in this order:
   -Wall -Werror -Wno-error=foo

Change-Id: I38c820bffc8277d909391e9bf557db5347836b9c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2014-01-13 22:46:50 +01:00
Thiago Macieira
d82ec6a168 Add -Werror support for the regular Clang, not Apple's
Base modules already work and produce no warnings.

Change-Id: I932d7aaecbe3404f180e185bf1e9fff4d488a05d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2014-01-10 19:31:31 +01:00
Tor Arne Vestbø
c760d2dbfd Rewrite qmake's exclusive-build feature
We used to compute the default exclusive build directory, eg 'debug', at
configure time, and then set OBJECTS_DIR, MOC_DIR, etc to include this
hard-coded default exclusive build directory. We then had to run a post-
process step where we replaced the 'debug' part with the current actual
exclusive build pass, eg 'release', resulting in long-standing bugs such
as QTBUG-491 where we end up replacing parts of the build output dirs
that were not part of the original exclusive build directory.

We now set the OBJECTS_DIR, MOC_DIR, etc defaults in configure like
before, but they do not include any exclusive-build information. The
exclusive build directory is handled as a separate step in default_post
where we adjust all entries in QMAKE_DIR_REPLACE to be exclusive
directories.

For backwards compatibility the new exclusive build behavior is only
enabled for variables named by QMAKE_DIR_REPLACE_SANE, which for Qt
itself applies globally to everything but DESTDIR, and for libs and
tools also applies to DESTDIR. The reason for leaving out DESTDIR in
the general case is because many tests and examples assume the old
behavior for DESTDIR. A side effect of including all the other
variables for Qt libs and tools is that the PCH output dir will be
uniformly set, which has been an issue on Windows in the past.

The addExclusiveBuilds function now takes two or more arguments,
each argument being the key for an exclusive build, which can be
customized eg. using $$key.{name,target,dir_affix}. Passing more
than two arguments results in three/four/etc-way exclusive builds,
eg debug/release/profile. Exclusive builds can also be combined, eg
static/shared + debug/release by making two calls to the function.

We also handle individual targets of combined exclusive builds,
eg static/shared + debug/release, meaning it is possible to run
'make debug' to build both static-debug and shared-debug.

Task-number: QTBUG-491
Change-Id: I02841dbbd065ac07d413dfb45cfcfe4c013674ac
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-10-25 20:50:51 +02:00
Eskil Abrahamsen Blomfeldt
de1f9bdc15 Android: Never error out on literal-suffix warning
When warnings are treated as errors, no Android code will
compile, since one of the platform headers in the NDK triggers
the literal-suffix warning. So we need to mark this as no-error.

Change-Id: Icabf1c2f2d32f76ee157d04e62a28f83abeed8f1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2013-09-20 23:45:06 +02:00
Thiago Macieira
f62b05ccf1 Fix -Wno-error=deprecated for GCC and Clang
Commit a7ba0ad93e introduced the -Wno-
language. The warning about deprecated functions, variables or types is
-Wdeprecated-declarations.

Change-Id: I6d269851afefc6a3fc3bf6599c3c702eb164245e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-09-04 00:05:12 +02:00
Thiago Macieira
a7ba0ad93e Make sure deprecation warnings don't cause errors with -Werror
It sounds like a good thing to have this warning, but for
future-proofing we can't have it. The system libraries might change
and add deprecation marks (OS X does that often). If they do that, we
don't want poor developers to have to fix all warnings before they can
build Qt again.

Change-Id: I4ff317da0de596c470bb1efe6e59bcf70aeec8fc
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-08-27 03:50:58 +02:00
Thiago Macieira
043b809197 Set an upper range of compiler versions for -Werror
This allows us to go back to older versions of Qt with newer compilers,
that didn't exist when those versions were released. It also allows
someone upgrading their compiler and not being faced with having to fix
all warnings before Qt compiles.

This commit whitelists the following compilers:
* Apple Clang versions 4.0, 4.1 and 4.2 (OS X only)
* Intel Compiler versions 13.0, 13.1 and 14.0 (Linux only)
* GCC versions 4.6, 4.7 and 4.8 (all OS)

Notably, Clang on other other OS besides OS X and MSVC are missing.

Change-Id: I665160d40a59336da1904f2a6c1eda543e592b48
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-08-23 18:56:09 +02:00
Thiago Macieira
ebfd85a499 Add the infrastructure to compile Qt with -Werror
This is enabled only for -developer-builds and only for certain
compiler-version combinations that are in a whitelist.

It also requires each library, plugin or tool to declare whether it is
supposedly clean of warnings. When most targets are clean, we can
consider inverting.

Change-Id: I17b5c4e45aee5078f9788e846a45d619c144095a
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-02-28 23:43:36 +01:00
Thiago Macieira
267567b8da Enable C++11 mode for Qt tools too
Change-Id: Ifb93e6ed1046142a9f57c7546ddf926532efd868
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
2013-02-28 05:43:25 +01:00
Thiago Macieira
bb6b2f4073 Add qt_common.prf and move some common definitions there
This file is now included by three types of Qt output: modules,
plugins (including QML plugins) and tools.

Change-Id: I5085f6ff37f70e9228303bf0520040adc2e2d7a5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-02-28 05:43:18 +01:00