AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
f54f7d8470
qt5base-lts/mkspecs/features/default_post.prf

151 lines
5.0 KiB
Plaintext
Raw Normal View History

add some docu about the project loading sequence Change-Id: Icb6bb58247724aeb6b9433a8d032718f1ba4babe Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2012-12-11 21:22:23 +00:00
# This file is loaded by qmake right after loading the actual project file.
define have_target CONFIG flag the check whether we are building a lib or an app (and thus have a target) is done by quite some feature files (and generally wrongly, as they do not account for the new aux target), so centralize it in default_post.prf. Change-Id: I868edbc4185be8a6c23ecd4a2c126024d73cdeb4 Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
2012-04-10 12:18:20 +00:00
contains(TEMPLATE, ".*(lib|app)"):CONFIG += have_target
remove qt from CONFIG for non-artifact templates there is no point in adding Qt modules to SUBDIRS projects. as QT contains core and gui by default, the operations are relatively expensive, so skip them when they are unneeded. Change-Id: Ibe6447ff452e403cb040fabe245d248edbda0eaa Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
2012-04-03 17:27:55 +00:00
!have_target:!force_qt: CONFIG -= qt
refactor build config resolution the current approach of having "free-flying" prf files for such a core issue is rather insane. this was noticed early on, as evidenced by the forcible loading of debug/release/debug_and_release in default_post. however, things remained a mess, in particular static vs. shared. consequently, the commit merges all related feature files. the actual config resolution is put in a separate feature file, so it can be loaded by resolve_target if that happens to be loaded early on. Change-Id: Ie30e7c63cabe9409a3263ca1650e323a870926f2 Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2013-02-15 17:15:18 +00:00
load(resolve_config)
Update the macros for shared/DLL and static builds Up until now, we had a mess of different macros used for building DLLs, for building shared libraries on Unix systems and for building static libraries. Some of the macros were contradictory and did not work. From now on, there shall be only: - QT_STATIC: indicates that it's a static Qt build and the export macros should expand to empty - QT_SHARED: indicates that it's a shared / dynamic Qt build and the export macros should expand to Q_DECL_EXPORT or Q_DECL_IMPORT, depending on whether the macro corresponds to the current module being built (the QT_BUILD_XXXX_LIB macro comes from the module's .pro file) QT_BOOTSTRAPPED implies QT_STATIC since the bootstrapped tools link statically to some source code. QT_STATIC is recorded in qconfig.h by configure when Qt is configured for static builds. Nothing is recorded for a shared / dynamic build, so QT_SHARED is implied if nothing is defined. This allows for the existence of a static_and_shared build: with nothing recorded, defining QT_STATIC before qglobal.h causes the export macros to be that of the static form. Linking to the static libraries is out of the scope of this change (something for the buildsystem and linker to figure out). From this commit on, the proper way of declaring the export macros for a module called QtFoo is: #ifndef QT_STATIC # ifdef QT_BUILD_FOO_LIB # define Q_FOO_EXPORT Q_DECL_EXPORT # else # define Q_FOO_EXPORT Q_DECL_IMPORT # endif #else # define Q_FOO_EXPORT #endif The type of the Qt build is recorded in QT_CONFIG (in qconfig.pri) so all Qt modules build by default the same type of library. The keywords are "static" and "shared", used in both QT_CONFIG and CONFIG. The previous keyword of "staticlib" is deprecated and should not be used. Discussed-on: http://lists.qt-project.org/pipermail/development/2012-April/003172.html Change-Id: I127896607794795b681c98d08467efd8af49bcf3 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2012-05-30 10:09:00 +00:00
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-08 17:41:16 +00:00
exclusive_builds: load(exclusive_builds_post)
qmake: Centralize TARGET sanitization in default_post.prf Shared between UNIX and Win generators, and allows prfs after default_post to rely on sane TARGET and DESTDIR values. This allows us to clean up the DESTDIR logic in testcase.prf, which was completely busted. Doing the two in separate commits is unfortunately not possible as the old testcase.prf logic was so broken it would barf if only looked at. Change-Id: Ibf21216195c760ee46ae679c162b207b77a9d813 Reviewed-by: Jan Arve Sæther <jan-arve.saether@digia.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-10-07 15:55:45 +00:00
# If the TARGET looks like a path, split it into DESTDIR and the resulting TARGET
target_dir_part = $$dirname(TARGET)
!isEmpty(target_dir_part) {
isEmpty(DESTDIR): \
DESTDIR = $$target_dir_part
else: \
DESTDIR = $$DESTDIR/$$target_dir_part
TARGET = $$basename(TARGET)
DESTDIR = $$clean_path($$DESTDIR)
}
Initial import from the monolithic Qt. This is the beginning of revision history for this module. If you want to look at revision history older than this, please refer to the Qt Git wiki for how to use Git history grafting. At the time of writing, this wiki is located here: http://qt.gitorious.org/qt/pages/GitIntroductionWithQt If you have already performed the grafting and you don't see any history beyond this commit, try running "git log" with the "--follow" argument. Branched from the monolithic repo, Qt master branch, at commit 896db169ea224deb96c59ce8af800d019de63f12
2011-04-27 10:05:43 +00:00
QT_BREAKPAD_ROOT_PATH = $$(QT_BREAKPAD_ROOT_PATH)
!isEmpty(QT_BREAKPAD_ROOT_PATH): \ # quick test first whether requested ...
take advantage of new safety regarding build config resolution all tests that happen after default_post loads resolve_config can rely on debug vs. release, static vs. shared, and staticlib vs. dll being properly "de-conflicted". Change-Id: Ie0b4defcd6024bd1c25f53ba7e03621052d96492 Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2013-02-15 17:15:22 +00:00
!static:release:have_target: \ # is it applicable?
Initial import from the monolithic Qt. This is the beginning of revision history for this module. If you want to look at revision history older than this, please refer to the Qt Git wiki for how to use Git history grafting. At the time of writing, this wiki is located here: http://qt.gitorious.org/qt/pages/GitIntroductionWithQt If you have already performed the grafting and you don't see any history beyond this commit, try running "git log" with the "--follow" argument. Branched from the monolithic repo, Qt master branch, at commit 896db169ea224deb96c59ce8af800d019de63f12
2011-04-27 10:05:43 +00:00
!contains(TARGET, .*phony_target.*): \ # monster hack, you don't really see this here, right? ;)
system($$QT_BREAKPAD_ROOT_PATH/qtbreakpadsymbols --breakpad-exists) { # do we really have it?
Make it possible to force generation of debug info in release builds Change-Id: Ie79e5a6a87475d5140163a2a547b4385a53fc05f Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
2012-08-07 20:22:38 +00:00
CONFIG += breakpad force_debug_info
Initial import from the monolithic Qt. This is the beginning of revision history for this module. If you want to look at revision history older than this, please refer to the Qt Git wiki for how to use Git history grafting. At the time of writing, this wiki is located here: http://qt.gitorious.org/qt/pages/GitIntroductionWithQt If you have already performed the grafting and you don't see any history beyond this commit, try running "git log" with the "--follow" argument. Branched from the monolithic repo, Qt master branch, at commit 896db169ea224deb96c59ce8af800d019de63f12
2011-04-27 10:05:43 +00:00
CONFIG -= no_debug_info separate_debug_info
Make it possible to force generation of debug info in release builds Change-Id: Ie79e5a6a87475d5140163a2a547b4385a53fc05f Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
2012-08-07 20:22:38 +00:00
}
complete implementation of force_debug_info that means further detaching the generation and installation of debug info from the thing calling itself A Debug Build. Task-number: QTBUG-32412 Change-Id: I4d79d1ae4806c8e4a2d6a7ccd030fb88385dd7d4 Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2013-11-18 20:39:08 +00:00
force_debug_info|debug: \
CONFIG += debug_info
Make it possible to force generation of debug info in release builds Change-Id: Ie79e5a6a87475d5140163a2a547b4385a53fc05f Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
2012-08-07 20:22:38 +00:00
force_debug_info {
Initial import from the monolithic Qt. This is the beginning of revision history for this module. If you want to look at revision history older than this, please refer to the Qt Git wiki for how to use Git history grafting. At the time of writing, this wiki is located here: http://qt.gitorious.org/qt/pages/GitIntroductionWithQt If you have already performed the grafting and you don't see any history beyond this commit, try running "git log" with the "--follow" argument. Branched from the monolithic repo, Qt master branch, at commit 896db169ea224deb96c59ce8af800d019de63f12
2011-04-27 10:05:43 +00:00
QMAKE_CFLAGS_RELEASE = $$QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO
QMAKE_CXXFLAGS_RELEASE = $$QMAKE_CXXFLAGS_RELEASE_WITH_DEBUGINFO
QMAKE_LFLAGS_RELEASE = $$QMAKE_LFLAGS_RELEASE_WITH_DEBUGINFO
}
Add configure flag to optimize Qt for size 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>
2017-04-07 13:49:10 +00:00
optimize_size {
!isEmpty(QMAKE_CFLAGS_OPTIMIZE):!isEmpty(QMAKE_CFLAGS_OPTIMIZE_SIZE) {
QMAKE_CFLAGS_RELEASE -= $$QMAKE_CFLAGS_OPTIMIZE
QMAKE_CXXFLAGS_RELEASE -= $$QMAKE_CFLAGS_OPTIMIZE
QMAKE_CFLAGS_RELEASE += $$QMAKE_CFLAGS_OPTIMIZE_SIZE
QMAKE_CXXFLAGS_RELEASE += $$QMAKE_CFLAGS_OPTIMIZE_SIZE
}
} else: optimize_full {
Add optimize_full qmake config option This patch adds a new config option to qmake to enable full optimization where it makes sense. This currently is supported on all gcc like compilers by exchanging -O2 for -O3. In qtbase it is used to enable full optimizations on qtcore and qtgui and in a later patch can be used to replace similar existing logic in QtWebKit's WTF and JavaScriptCore modules. This fixes a performance regression from gcc 4.7 to 4.8 in the software renderer. An aliasing error in qregion.cpp which was exposed by more aggresive optimization has been solved as well. Change-Id: Ic2c6c41b79cb3846212b40e7bcc11ff492beb27f Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2014-02-14 12:57:35 +00:00
!isEmpty(QMAKE_CFLAGS_OPTIMIZE):!isEmpty(QMAKE_CFLAGS_OPTIMIZE_FULL) {
QMAKE_CFLAGS_RELEASE -= $$QMAKE_CFLAGS_OPTIMIZE
QMAKE_CXXFLAGS_RELEASE -= $$QMAKE_CFLAGS_OPTIMIZE
QMAKE_CFLAGS_RELEASE += $$QMAKE_CFLAGS_OPTIMIZE_FULL
QMAKE_CXXFLAGS_RELEASE += $$QMAKE_CFLAGS_OPTIMIZE_FULL
}
}
Optimize debug builds when -Og is available Enables optimizing with -Og if GCC has the option available, this should produce faster debug binaries without compromising debugability. Is a privateConfig to limit it to the default Qt build. Includes two fixes for false positives of maybe_uninitialized triggered by -Og on gcc 4.9. Change-Id: I466d7a4070295714189024369312e6cbd36cfacf Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
2016-11-17 14:01:59 +00:00
optimize_debug {
QMAKE_CFLAGS_DEBUG += $$QMAKE_CFLAGS_OPTIMIZE_DEBUG
QMAKE_CXXFLAGS_DEBUG += $$QMAKE_CFLAGS_OPTIMIZE_DEBUG
}
refactor build config resolution the current approach of having "free-flying" prf files for such a core issue is rather insane. this was noticed early on, as evidenced by the forcible loading of debug/release/debug_and_release in default_post. however, things remained a mess, in particular static vs. shared. consequently, the commit merges all related feature files. the actual config resolution is put in a separate feature file, so it can be loaded by resolve_target if that happens to be loaded early on. Change-Id: Ie30e7c63cabe9409a3263ca1650e323a870926f2 Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2013-02-15 17:15:18 +00:00
debug {
QMAKE_CFLAGS += $$QMAKE_CFLAGS_DEBUG
QMAKE_CXXFLAGS += $$QMAKE_CXXFLAGS_DEBUG
QMAKE_LFLAGS += $$QMAKE_LFLAGS_DEBUG
QMAKE_LIBFLAGS += $$QMAKE_LIBFLAGS_DEBUG
} else {
QMAKE_CFLAGS += $$QMAKE_CFLAGS_RELEASE
QMAKE_CXXFLAGS += $$QMAKE_CXXFLAGS_RELEASE
QMAKE_LFLAGS += $$QMAKE_LFLAGS_RELEASE
QMAKE_LIBFLAGS += $$QMAKE_LIBFLAGS_RELEASE
}
Enable stack-protector-strong for QNX 7.0.0 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>
2017-04-24 13:53:57 +00:00
stack_protector_strong {
QMAKE_CFLAGS += $$QMAKE_CFLAGS_STACK_PROTECTOR_STRONG
QMAKE_CXXFLAGS += $$QMAKE_CFLAGS_STACK_PROTECTOR_STRONG
}
Disable gold linker/new dtags support for host builds There is no test for gold linker and new dtags support for the host build (only for the target compiler/build) which leads to trouble in some cross compiling environments (see [1] for details). So disable gold linker/new dtags support unconditionally for host builds. [1] http://lists.busybox.net/pipermail/buildroot/2015-May/128303.html Task-number: QTBUG-46125 Change-Id: Ic62828704dcce461487d63860705158cce3e4af8 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
2015-05-19 19:30:21 +00:00
# disable special linker flags for host builds (no proper test for host support yet)
utilize configure results better in native builds don't ignore detected features for host tools when we're not actually cross-building. Change-Id: Id62a3c1c6b7ae422b14efb4fbea0892b05a047cc Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: René J.V. Bertin <rjvbertin@gmail.com>
2017-01-19 20:54:41 +00:00
!host_build|!cross_compile {
Disable gold linker/new dtags support for host builds There is no test for gold linker and new dtags support for the host build (only for the target compiler/build) which leads to trouble in some cross compiling environments (see [1] for details). So disable gold linker/new dtags support unconditionally for host builds. [1] http://lists.busybox.net/pipermail/buildroot/2015-May/128303.html Task-number: QTBUG-46125 Change-Id: Ic62828704dcce461487d63860705158cce3e4af8 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
2015-05-19 19:30:21 +00:00
use_gold_linker: QMAKE_LFLAGS += $$QMAKE_LFLAGS_USE_GOLD
enable_new_dtags: QMAKE_LFLAGS += $$QMAKE_LFLAGS_NEW_DTAGS
}
Introduce qmake feature use_gold_linker This patch adds the feature use_gold_linker to use the gold linker that has been part of of GNU binutils since 2008. Gold links C++ libraries much faster and use less memory. The feature is autodetected when building Qt on Linux, but can be disabled in configure. On MingW builds it is default off but can be enabled for cross builds. Change-Id: Icdd6ba2e706b2c791bcf44b6e718c2b7a5eb2218 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2014-07-01 09:46:50 +00:00
refactor build config resolution the current approach of having "free-flying" prf files for such a core issue is rather insane. this was noticed early on, as evidenced by the forcible loading of debug/release/debug_and_release in default_post. however, things remained a mess, in particular static vs. shared. consequently, the commit merges all related feature files. the actual config resolution is put in a separate feature file, so it can be loaded by resolve_target if that happens to be loaded early on. Change-Id: Ie30e7c63cabe9409a3263ca1650e323a870926f2 Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2013-02-15 17:15:18 +00:00
dll:win32: QMAKE_LFLAGS += $$QMAKE_LFLAGS_DLL
static:mac: QMAKE_LFLAGS += $$QMAKE_LFLAGS_STATIC_LIB
staticlib:unix {
QMAKE_CFLAGS += $$QMAKE_CFLAGS_STATIC_LIB
QMAKE_CXXFLAGS += $$QMAKE_CXXFLAGS_STATIC_LIB
}
Initial import from the monolithic Qt. This is the beginning of revision history for this module. If you want to look at revision history older than this, please refer to the Qt Git wiki for how to use Git history grafting. At the time of writing, this wiki is located here: http://qt.gitorious.org/qt/pages/GitIntroductionWithQt If you have already performed the grafting and you don't see any history beyond this commit, try running "git log" with the "--follow" argument. Branched from the monolithic repo, Qt master branch, at commit 896db169ea224deb96c59ce8af800d019de63f12
2011-04-27 10:05:43 +00:00
incredibuild_xge {
CONFIG -= incredibuild_xge
CONFIG = incredibuild_xge $$CONFIG
}
Fix interaction between sdk.prf and silent.prf The 'silent' option to CONFIG will mangle QMAKE_CXX and friends by prepending an @echo, which sdk.prf doesn't handle (it assumes the variables contain names of executables, with optional arguments). Instead of teaching sdk.prf generic command line parsing we ensure that silent.prf does its job at the very end, when the tools have already had their paths fixed by sdk.prf. Change-Id: I7093232e5cc37ed8106a3b838f42ad8f1a43fb86 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
2013-03-14 14:51:37 +00:00
silent {
# Ensure that we process silent.prf last, as it will mangle QMAKE_CXX
# and friends in a way that some of the other features (sdk.prf and
# simd.prf eg) do not handle.
CONFIG -= silent
CONFIG = silent $$CONFIG
}
Make it possible to force generation of debug info in release builds Change-Id: Ie79e5a6a87475d5140163a2a547b4385a53fc05f Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
2012-08-07 20:22:38 +00:00
breakpad {
load(resolve_target)
untangle use of system vs. shell path(-list) semantics "system" refers to the system's native shell, which is what qmake's system() invokes, and whose convention by far most commands invoked from a makefile will need. "shell" refers to the shell invoked by make, which diverges from the system shell only when qmake/mingw32-make is called from an msys shell. its conventions need to be used for anything the shell itself does (e.g., assembling env variables, but also command line argument unquoting) and the commands the mkspec sets according to the shell (e.g., QMAKE_MOVE). Change-Id: I0000aa9417c199cf8a810619d31ded24bb0675f9 Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2014-04-29 18:15:21 +00:00
DEBUGFILENAME = $$shell_quote($$system_path($$QMAKE_RESOLVED_TARGET))
PROJECTPATH = $$shell_quote($$system_path($$OUT_PWD))
Initial import from the monolithic Qt. This is the beginning of revision history for this module. If you want to look at revision history older than this, please refer to the Qt Git wiki for how to use Git history grafting. At the time of writing, this wiki is located here: http://qt.gitorious.org/qt/pages/GitIntroductionWithQt If you have already performed the grafting and you don't see any history beyond this commit, try running "git log" with the "--follow" argument. Branched from the monolithic repo, Qt master branch, at commit 896db169ea224deb96c59ce8af800d019de63f12
2011-04-27 10:05:43 +00:00
!isEmpty(QMAKE_POST_LINK):QMAKE_POST_LINK = $$QMAKE_POST_LINK$$escape_expand(\\n\\t)
make use of new functions makes for cleaner code Change-Id: I1a86bc4cac3778a1df37aa3307e5a8edac246961 Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
2012-07-12 09:16:53 +00:00
QMAKE_POST_LINK = $$QMAKE_POST_LINK$$quote($${QT_BREAKPAD_ROOT_PATH}$${QMAKE_DIR_SEP}qtbreakpadsymbols $$DEBUGFILENAME $$PROJECTPATH)
!isEmpty(QMAKE_STRIP):QMAKE_POST_LINK = $$QMAKE_POST_LINK$$escape_expand(\\n\\t)$$quote($$QMAKE_STRIP $$DEBUGFILENAME)
Initial import from the monolithic Qt. This is the beginning of revision history for this module. If you want to look at revision history older than this, please refer to the Qt Git wiki for how to use Git history grafting. At the time of writing, this wiki is located here: http://qt.gitorious.org/qt/pages/GitIntroductionWithQt If you have already performed the grafting and you don't see any history beyond this commit, try running "git log" with the "--follow" argument. Branched from the monolithic repo, Qt master branch, at commit 896db169ea224deb96c59ce8af800d019de63f12
2011-04-27 10:05:43 +00:00
}
Detect the (stated) C++ standard edition at build time 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>
2017-03-04 17:33:35 +00:00
!c++11:!c++14:!c++1z {
# Qt requires C++11 since 5.7, check if we need to force a compiler option
QT_COMPILER_STDCXX_no_L = $$replace(QT_COMPILER_STDCXX, "L$", "")
!greaterThan(QT_COMPILER_STDCXX_no_L, 199711): CONFIG += c++11
}
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-07-09 00:21:30 +00:00
c++11|c++14|c++1z {
Merge remote-tracking branch 'origin/5.6' into 5.7 This change partially reverts 1bfc7f68 about QT_HAS_BUILTIN define and undef in src/corelib/tools/qsimd_p.h. This change is also squashed with "Fall back to c++11 standard compiler flag for host builds" which is done by Peter Seiderer. Conflicts: mkspecs/features/default_post.prf src/3rdparty/sqlite/0001-Fixing-the-SQLite3-build-for-WEC2013-again.patch src/3rdparty/sqlite/sqlite3.c src/corelib/tools/qsimd_p.h src/gui/kernel/qevent.cpp src/gui/kernel/qwindowsysteminterface.cpp src/gui/kernel/qwindowsysteminterface_p.h src/plugins/bearer/blackberry/blackberry.pro src/plugins/platforms/cocoa/qcocoasystemsettings.mm src/plugins/platformthemes/gtk2/gtk2.pro src/plugins/styles/bb10style/bb10style.pro src/sql/drivers/sqlite2/qsql_sqlite2.cpp tools/configure/configureapp.cpp Task-number: QTBUG-51644 Done-with: Peter Seiderer <ps.report@gmx.net> Change-Id: I6100d6ace31b2e8d41a95f0b5d5ebf8f1fd88b44
2016-03-10 15:39:05 +00:00
# Disable special compiler flags for host builds
!host_build|!cross_compile {
c++1z: cxxstd = CXX1Z
else: c++14: cxxstd = CXX14
else: cxxstd = CXX11
} else {
# Fall back to c++11, because since 5.7 c++11 is required everywhere,
# including host builds
cxxstd = CXX11
}
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-07-09 00:21:30 +00:00
MSVC: Enable standard-conformance mode by default 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>
2017-05-03 20:07:18 +00:00
# Check if we should disable compiler extensions or not
isEmpty(QMAKE_CXXFLAGS_GNU$$cxxstd) {
strict_c++: QMAKE_CXXFLAGS += $$QMAKE_CXXFLAGS_STRICTCXX
} else {
!strict_c++: cxxstd = GNU$$cxxstd
}
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-07-09 00:21:30 +00:00
QMAKE_CXXFLAGS += $$eval(QMAKE_CXXFLAGS_$$cxxstd)
QMAKE_LFLAGS += $$eval(QMAKE_LFLAGS_$$cxxstd)
unset(cxxstd)
}
Turn on -utf-8 compiler option for msvc2015 update 2 and up Building qt with msvc would fail with the -developer-build configure option turned on under simplified chinese locale. This is because msvc will emit warnings for source files with utf-8 characters which are not representable in CP936, and -developer-build implies treating warnings as errors. This patch turn on -utf-8 compiler option for msvc2015 update 2 and up only for building qt. Task-number: QTBUG-58161 Change-Id: If38ea11eb1f39f8e08efa1cccb92e0eea50daf92 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
2017-01-30 08:13:59 +00:00
utf8_source {
QMAKE_CFLAGS += $$QMAKE_CFLAGS_UTF8_SOURCE
QMAKE_CXXFLAGS += $$QMAKE_CFLAGS_UTF8_SOURCE
}
Move no-pch extra compiler to common features As we add more classes with RValue ref qualified methods we will need the same _compat trick and no-pch support as QString. This patch moves the extra compiler to precompile_header.prf which is automatically included when pch is used. Change-Id: I422a355fd11f499ce0648a90b0385f2a6f699fcb Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2014-01-06 15:41:53 +00:00
!precompile_header: SOURCES += $$NO_PCH_SOURCES
Reference in New Issue Copy Permalink