qt5base-lts/mkspecs/features/default_post.prf

89 lines
3.0 KiB
Plaintext
Raw Normal View History

# This file is loaded by qmake right after loading the actual project file.
contains(TEMPLATE, ".*(lib|app)"):CONFIG += have_target
!have_target:!force_qt: CONFIG -= qt
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)
# 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)
}
QT_BREAKPAD_ROOT_PATH = $$(QT_BREAKPAD_ROOT_PATH)
!isEmpty(QT_BREAKPAD_ROOT_PATH): \ # quick test first whether requested ...
!static:release:have_target: \ # is it applicable?
!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?
CONFIG += breakpad force_debug_info
CONFIG -= no_debug_info separate_debug_info
}
force_debug_info {
QMAKE_CFLAGS_RELEASE = $$QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO
QMAKE_CXXFLAGS_RELEASE = $$QMAKE_CXXFLAGS_RELEASE_WITH_DEBUGINFO
QMAKE_LFLAGS_RELEASE = $$QMAKE_LFLAGS_RELEASE_WITH_DEBUGINFO
}
debug {
QMAKE_CFLAGS += $$QMAKE_CFLAGS_DEBUG
QMAKE_CXXFLAGS += $$QMAKE_CXXFLAGS_DEBUG
QMAKE_OBJECTIVE_CFLAGS += $$QMAKE_OBJECTIVE_CFLAGS_DEBUG
QMAKE_LFLAGS += $$QMAKE_LFLAGS_DEBUG
QMAKE_LIBFLAGS += $$QMAKE_LIBFLAGS_DEBUG
} else {
QMAKE_CFLAGS += $$QMAKE_CFLAGS_RELEASE
QMAKE_CXXFLAGS += $$QMAKE_CXXFLAGS_RELEASE
QMAKE_OBJECTIVE_CFLAGS += $$QMAKE_OBJECTIVE_CFLAGS_RELEASE
QMAKE_LFLAGS += $$QMAKE_LFLAGS_RELEASE
QMAKE_LIBFLAGS += $$QMAKE_LIBFLAGS_RELEASE
}
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
}
incredibuild_xge {
CONFIG -= incredibuild_xge
CONFIG = incredibuild_xge $$CONFIG
}
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
}
force_debug_info:win32 {
load(resolve_target)
QMAKE_CLEAN += $$replace(QMAKE_RESOLVED_TARGET, ...$, pdb) # for the debug case it is hardcoded in qmake
}
breakpad {
load(resolve_target)
DEBUGFILENAME = $$shell_quote($$shell_path($$QMAKE_RESOLVED_TARGET))
PROJECTPATH = $$shell_quote($$shell_path($$OUT_PWD))
!isEmpty(QMAKE_POST_LINK):QMAKE_POST_LINK = $$QMAKE_POST_LINK$$escape_expand(\\n\\t)
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)
}
QMAKE_INCDIR += $$QMAKE_INCDIR_POST
QMAKE_LIBDIR += $$QMAKE_LIBDIR_POST