qt5base-lts/mkspecs/features/qt.prf

395 lines
15 KiB
Plaintext
Raw Normal View History

# This avoids spurious errors when a project is explicitly disabled
# due to required Qt modules being missing.
!isEmpty(QMAKE_FAILED_REQUIREMENTS): return()
# hardcoded defaults
QT_CONFIG *= c99 c11 c++11 c++14 c++1z c++17
qtConfig(thread): CONFIG *= thread
#handle defines
win32 {
qtConfig(shared) {
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
# this variable is read by qmake in qmake/generators/win32/msvc_vcproj.cpp
# function VcprojGenerator::initDeploymentTool()
QMAKE_DLL_PATHS += $$[QT_INSTALL_BINS/get]
}
}
CONFIG(release, debug|release):DEFINES += QT_NO_DEBUG
no_keywords:DEFINES += QT_NO_KEYWORDS
plugin { #Qt plugins
static:DEFINES += QT_STATICPLUGIN
DEFINES += QT_PLUGIN
}
qtestlib {
warning("CONFIG+=qtestlib is deprecated. Use QT+=testlib instead.")
QT += testlib
}
qdbus {
warning("CONFIG+=qdbus is deprecated. Use QT+=dbus instead.")
QT += dbus
}
help {
warning("CONFIG+=help is deprecated. Use QT+=help instead.")
QT += help-private # sic!
}
designer {
warning("CONFIG+=designer is deprecated. Use QT+=designer instead.")
QT += designer
}
uitools {
warning("CONFIG+=uitools is deprecated. Use QT+=uitools instead.")
QT += uitools
}
qaxcontainer {
warning("CONFIG+=qaxcontainer is deprecated. Use QT+=axcontainer instead.")
QT += axcontainer
}
qaxserver {
warning("CONFIG+=qaxserver is deprecated. Use QT+=axserver instead.")
QT += axserver
}
!import_qpa_plugin {
warning("CONFIG-=import_qpa_plugin is deprecated. Use QTPLUGIN.platforms=- instead.")
QTPLUGIN.platforms = -
} else: qpa_minimal_plugin {
warning("CONFIG+=qpa_minimal_plugin is deprecated. Use QTPLUGIN.platforms=qminimal instead.")
QTPLUGIN.platforms = qminimal
}
!force_import_plugins:!contains(TEMPLATE, ".*app"):!if(contains(TEMPLATE, ".*lib"):dll): \
CONFIG -= import_plugins
Enable -mno-direct-extern-access and ELF protected visibility The -mno-direct-extern-access tells the compiler and linker that references to symbols outside this ELF module mustn't be direct and must instead always go through the GOT or PLT (the PLT can additionally be disabled with -fno-plt). The ELF protected visibility tells the compiler and linker that this symbol is present in the dynamic symbol table as an export, but it cannot be interposed by another ELF module. This option is required for user code to link properly to Qt, otherwise they will get linker errors (assuming GNU binutils >= 2.39) or runtime failures (glibc >= 2.35). Both versions of glibc and binutils are older than GCC 12, so it's a safe assumption they are in use and downgrading the toolchain or libc is not supported. Adding this option to the compilation is assured for CMake and qmake-based projects. For example, all accessess to QCoreApplication::self in QtCore, after this change and with GCC 12 are relocation-free and direct: 000000000013ebf0 <QCoreApplicationPrivate::checkInstance(char const*)>: 13ebf0: cmpq $0x0,0x4f73d0(%rip) # 635fc8 <QCoreApplication::self> 13ebf8: setne %al 13ebfb: je a90fe <QCoreApplicationPrivate::checkInstance(char const*) [clone .cold]> 13ec01: ret Meanwhile, accesses to the same variable in other modules are indirect via the GOT: 66650: mov 0x876e1(%rip),%rax # edd38 <QCoreApplication::self@Qt_6> 66657: cmpq $0x0,(%rax) This replaces the -Bsymbolic and -Bsymbolic-functions (broken) functionality that Qt has been using or attempting to use since ~2006. See https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_606975128 Change-Id: Iad4b0a3e5c06570b9f5f571b26ed564aa0811e47 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
2012-01-23 13:46:58 +00:00
unix {
contains(QT_CONFIG, no_direct_extern_access): CONFIG += no_direct_extern_access
Enable -mno-direct-extern-access and ELF protected visibility The -mno-direct-extern-access tells the compiler and linker that references to symbols outside this ELF module mustn't be direct and must instead always go through the GOT or PLT (the PLT can additionally be disabled with -fno-plt). The ELF protected visibility tells the compiler and linker that this symbol is present in the dynamic symbol table as an export, but it cannot be interposed by another ELF module. This option is required for user code to link properly to Qt, otherwise they will get linker errors (assuming GNU binutils >= 2.39) or runtime failures (glibc >= 2.35). Both versions of glibc and binutils are older than GCC 12, so it's a safe assumption they are in use and downgrading the toolchain or libc is not supported. Adding this option to the compilation is assured for CMake and qmake-based projects. For example, all accessess to QCoreApplication::self in QtCore, after this change and with GCC 12 are relocation-free and direct: 000000000013ebf0 <QCoreApplicationPrivate::checkInstance(char const*)>: 13ebf0: cmpq $0x0,0x4f73d0(%rip) # 635fc8 <QCoreApplication::self> 13ebf8: setne %al 13ebfb: je a90fe <QCoreApplicationPrivate::checkInstance(char const*) [clone .cold]> 13ec01: ret Meanwhile, accesses to the same variable in other modules are indirect via the GOT: 66650: mov 0x876e1(%rip),%rax # edd38 <QCoreApplication::self@Qt_6> 66657: cmpq $0x0,(%rax) This replaces the -Bsymbolic and -Bsymbolic-functions (broken) functionality that Qt has been using or attempting to use since ~2006. See https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_606975128 Change-Id: Iad4b0a3e5c06570b9f5f571b26ed564aa0811e47 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
2012-01-23 13:46:58 +00:00
else:contains(QT_CONFIG, reduce_relocations):!contains(TEMPLATE, .*lib): {
QMAKE_CFLAGS += $$QMAKE_CFLAGS_PIC
QMAKE_CXXFLAGS += $$QMAKE_CFLAGS_PIC
}
}
Add permission API backend for macOS and iOS When submitting applications to the iOS and macOS AppStore the application goes through static analysis, which will trigger on uses of various privacy protected APIs, unless the application has a corresponding usage description for the permission in the Info.plist file. This applies even if the application never requests the given permission, but just links to a Qt library that has the offending symbols or library dependencies. To ensure that the application does not have to add usage descriptions to their Info.plist for permissions they never plan to use we split up the various permission implementations into small static libraries that register with the Qt plugin mechanism as permission backends. We can then inspect the application's Info.plist at configure time and only add the relevant static permission libraries. Furthermore, since some permissions can be checked without any usage description, we allow the implementation to be split up into two separate translation units. By putting the request in its own translation unit we can selectively include it during linking by telling the linker to look for a special symbol. This is useful for libraries such as Qt Multimedia who would like to check the current permission status, but without needing to request any permission of its own. Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Change-Id: Ic2a43e1a0c45a91df6101020639f473ffd9454cc Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2022-05-10 13:02:43 +00:00
# Will automatically add plugins, so run first
contains(QT_CONFIG, permissions): load(permissions)
# qmake variables cannot contain dashes, so normalize the names first
CLEAN_QT = $$replace(QT, -private$, _private)
CLEAN_QT_PRIVATE = $$replace(QT_PRIVATE, -private$, _private)
qt_module_deps = $$CLEAN_QT $$CLEAN_QT_PRIVATE
all_qt_module_deps = $$resolve_depends(qt_module_deps, "QT.", ".depends" ".run_depends")
QTPLUGIN = $$unique($$list($$lower($$QTPLUGIN)))
# Sanitize requested plugins, and add any default plugins
import_plugins {
manualplugs = $$QTPLUGIN # User may specify plugins. Mostly legacy.
autoplugs = # Auto-added plugins.
# First round: explicitly specified modules.
all_plugin_deps = $$all_qt_module_deps
plugin_deps = $$all_plugin_deps
for(ever) {
# Automatically add the default plugins for the linked Qt modules.
for (qtmod, plugin_deps) {
for (ptype, QT.$${qtmod}.plugin_types) {
nptype = $$replace(ptype, [-/], _)
isEmpty(QTPLUGIN.$$nptype) {
for (plug, QT_PLUGINS) {
equals(QT_PLUGIN.$${plug}.TYPE, $$ptype) {
for (dep, QT_PLUGIN.$${plug}.EXTENDS) {
!contains(all_plugin_deps, $$dep) {
plug =
break()
}
}
autoplugs += $$plug
}
}
} else {
plug = $$eval(QTPLUGIN.$$nptype)
!equals(plug, -): \
autoplugs += $$plug
}
}
}
QTPLUGIN = $$manualplugs $$autoplugs
QTPLUGIN = $$unique(QTPLUGIN)
# Obtain the plugins' Qt dependencies ...
plugin_deps =
for (plug, QTPLUGIN): \
plugin_deps += $$eval(QT_PLUGIN.$${plug}.DEPENDS)
plugin_deps = $$resolve_depends(plugin_deps, "QT.", ".depends" ".run_depends")
plugin_deps -= $$all_plugin_deps
isEmpty(plugin_deps): \
break()
# ... and start over if any new Qt modules appeared,
# as these may want to load plugins in turn.
all_plugin_deps += $$plugin_deps
}
extraplugs = $$manualplugs
manualplugs -= $$autoplugs
extraplugs -= $$manualplugs
!isEmpty(extraplugs): \
warning("Redundant entries in QTPLUGIN: $$extraplugs")
}
# Link static plugins
!isEmpty(QTPLUGIN) {
for (plug, QTPLUGIN) {
module_config = $$eval(QT_PLUGIN.$${plug}.module_config)
isEmpty(module_config):!qtConfig(static): \
next() # Compatibility with older modules
!contains(module_config, staticlib): \
next()
plug_class = $$eval(QT_PLUGIN.$${plug}.CLASS_NAME)
!isEmpty(plug_class): \
IMPORT_FILE_CONT += "Q_IMPORT_PLUGIN($$plug_class)"
else: \
warning("Plugin class name could not be determined for plugin '$$plug'.")
plugin_deps = $$eval(QT_PLUGIN.$${plug}.DEPENDS)
plugin_deps = $$resolve_depends(plugin_deps, "QT.", ".depends" ".run_depends")
all_qt_module_deps *= $$plugin_deps
# Check if the plugin is known to Qt. We can use this to determine
# the plugin path. Unknown plugins must rely on the default link path.
plug_type = $$eval(QT_PLUGIN.$${plug}.TYPE)
!isEmpty(plug_type) {
qmake: Resolve target suffix based on Qt build config for static plugins The qtPlatformTargetSuffix() function is used in various places to determine the suffix of targets based on the config, which for macOS will result in a _debug suffix in debug mode. This becomes tricky when one project built in debug mode tries to depend on the libraries/plugins of another project (Qt) built in release, as the qtPlatformTargetSuffix() function uses the current CONFIG as input, which may be different than the QT_CONFIG (or CONFIG of whatever project is being depended on). For libraries this was fixed in 50e664835bc2130e8693364641f9aaa7133b6998 by iterating all known library paths, and trying the CONFIG suffix before falling back to release version. For plugins this was never solved, which becomes an issue when linking to static plugins, either in a fully static build of Qt, or when some of the plugins are static (permission plugins e.g.). In this situation, the user project has to have the same configuration as Qt was built with, to avoid errors like: error: no such file or directory: '~/6.x-static/qtbase/plugins/platforms/libqcocoa_debug.a' To work around this, we assume that a plugin installed into the Qt tree has the same build configuration as Qt itself, then then use QT_CONFIG as the determining factor when linking to the plugin. This still ties the build config of the plugin to the config of Qt, but relaxes the relationship to the application, allowing it to be built in either debug or release, which is an improvement to the current state. Pick-to: 6.5 6.5.0 Task-number: QTBUG-110356 Change-Id: Icee67fc01313a6c6f34178a6345ccae1b57429d7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-02-23 14:50:23 +00:00
# Respect target config if Qt provides both debug and release versions
# of each plugin. Otherwise, respect what Qt was configured with.
qtConfig(debug_and_release): config_variable = CONFIG
else: config_variable = QT_CONFIG
plug_name = $$QMAKE_PREFIX_STATICLIB$${plug}$$qtPlatformTargetSuffix($$config_variable).$$QMAKE_EXTENSION_STATICLIB
plug_path = $$eval(QT_PLUGIN.$${plug}.PATH)
isEmpty(plug_path): \
plug_path = $$[QT_INSTALL_PLUGINS/get]
LIBS += $$plug_path/$$plug_type/$$plug_name
} else {
qmake: Resolve target suffix based on Qt build config for static plugins The qtPlatformTargetSuffix() function is used in various places to determine the suffix of targets based on the config, which for macOS will result in a _debug suffix in debug mode. This becomes tricky when one project built in debug mode tries to depend on the libraries/plugins of another project (Qt) built in release, as the qtPlatformTargetSuffix() function uses the current CONFIG as input, which may be different than the QT_CONFIG (or CONFIG of whatever project is being depended on). For libraries this was fixed in 50e664835bc2130e8693364641f9aaa7133b6998 by iterating all known library paths, and trying the CONFIG suffix before falling back to release version. For plugins this was never solved, which becomes an issue when linking to static plugins, either in a fully static build of Qt, or when some of the plugins are static (permission plugins e.g.). In this situation, the user project has to have the same configuration as Qt was built with, to avoid errors like: error: no such file or directory: '~/6.x-static/qtbase/plugins/platforms/libqcocoa_debug.a' To work around this, we assume that a plugin installed into the Qt tree has the same build configuration as Qt itself, then then use QT_CONFIG as the determining factor when linking to the plugin. This still ties the build config of the plugin to the config of Qt, but relaxes the relationship to the application, allowing it to be built in either debug or release, which is an improvement to the current state. Pick-to: 6.5 6.5.0 Task-number: QTBUG-110356 Change-Id: Icee67fc01313a6c6f34178a6345ccae1b57429d7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-02-23 14:50:23 +00:00
LIBS += -l$${plug}$$qtPlatformTargetSuffix(CONFIG)
}
}
!isEmpty(IMPORT_FILE_CONT) {
IMPORT_FILE_CONT = \
"// This file is autogenerated by qmake. It imports static plugin classes for" \
"// static plugins specified using QTPLUGIN and QT_PLUGIN_CLASS.<plugin> variables." \
"$${LITERAL_HASH}include <QtPlugin>" \
"$$IMPORT_FILE_CONT"
TARGET_BASENAME = $$lower($$basename(TARGET))
TARGET_BASENAME ~= s/\s/_/g
IMPORT_CPP = $$OUT_PWD/$${TARGET_BASENAME}_plugin_import.cpp
write_file($$IMPORT_CPP, IMPORT_FILE_CONT)|error()
GENERATED_SOURCES += $$IMPORT_CPP
QMAKE_DISTCLEAN += $$IMPORT_CPP
}
}
# target variable, flag source variable
defineTest(qtProcessModuleFlags) {
for(flag, $$2) {
contains(flag, ^-.*): \
$$1 -= $$replace(flag, ^-, )
else: \
$$1 += $$flag
}
export($$1)
}
unset(using_private_headers)
var_sfx =
for(ever) {
# Topological resolution of modules based on their QT.<module>.depends variable
FULL_QT$$var_sfx = $$resolve_depends(CLEAN_QT$$var_sfx, "QT.")
# Finally actually add the modules
unset(BAD_QT)
for(QTLIB, FULL_QT$$var_sfx) {
MODULE_NAME = $$eval(QT.$${QTLIB}.name)
MODULE_MODULE = $$eval(QT.$${QTLIB}.module)
MODULE_INCLUDES = $$eval(QT.$${QTLIB}.includes)
MODULE_LDFLAGS = $$eval(QT.$${QTLIB}.ldflags)
MODULE_LIBS = $$eval(QT.$${QTLIB}.libs)
MODULE_FRAMEWORKS = $$eval(QT.$${QTLIB}.frameworks)
MODULE_USES = $$eval(QT.$${QTLIB}.uses)
MODULE_CONFIG = $$eval(QT.$${QTLIB}.module_config)
isEmpty(MODULE_NAME) {
BAD_QT += $$QTLIB
next()
}
contains(MODULE_CONFIG, internal_module):!isEmpty(MODULE_INCLUDES): \
using_private_headers = true
contains(MODULE_CONFIG, ltcg): \
CONFIG += link_ltcg
qtProcessModuleFlags(CONFIG, QT.$${QTLIB}.CONFIG)
qtProcessModuleFlags(DEFINES, QT.$${QTLIB}.DEFINES)
MODULE_INCLUDES -= $$QMAKE_DEFAULT_INCDIRS
# Add linker flags before lib
LIBS$$var_sfx += $$MODULE_LDFLAGS
# Frameworks shouldn't need include paths, but much code does not use
# module-qualified #includes, so by default we add paths which point
# directly into the frameworks. Private modules have somewhat convoluted
# header paths, so adding them is necessary in every case.
!if(contains(MODULE_CONFIG, lib_bundle):qt_no_framework_direct_includes) \
|contains(MODULE_CONFIG, internal_module): \
INCLUDEPATH *= $$MODULE_INCLUDES
QMAKE_FRAMEWORKPATH *= $$MODULE_FRAMEWORKS
!isEmpty(MODULE_MODULE) {
contains(MODULE_CONFIG, lib_bundle) {
macOS: Explicitly link to debug version of framework when needed 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>
2018-03-09 16:04:37 +00:00
framework = $$MODULE_MODULE
# Linking frameworks by absolute path does not work.
macOS: Explicitly link to debug version of framework when needed 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>
2018-03-09 16:04:37 +00:00
LIBS$$var_sfx += -framework $$framework
} else {
lib_bases = $$MODULE_MODULE$$qtPlatformTargetSuffix()
darwin: lib_bases *= $$MODULE_MODULE
add_lib_to_pretargetdeps = false
win32|contains(MODULE_CONFIG, staticlib) {
lib_prefix = $$MODULE_LIBS/$$QMAKE_PREFIX_STATICLIB
lib_suffixes = $$QMAKE_EXTENSION_STATICLIB
lib_suffixes *= $$QMAKE_LIB_EXTENSIONS
!xcodebuild: \
add_lib_to_pretargetdeps = true
} else {
lib_prefix = $$MODULE_LIBS/$$QMAKE_PREFIX_SHLIB
lib_suffixes = $$QMAKE_EXTENSION_SHLIB
}
candidates =
for(lib_base, lib_bases) {
for(lib_suffix, lib_suffixes) {
candidates += $${lib_prefix}$${lib_base}.$${lib_suffix}
}
}
lib =
for(candidate, candidates) {
exists("$$candidate") {
lib = "$$candidate"
break()
}
}
isEmpty(lib): \
lib = $$first(candidates)
$$add_lib_to_pretargetdeps: \
PRE_TARGETDEPS += $$lib
LIBS$$var_sfx += $$lib
}
}
QMAKE_USE$$var_sfx += $$MODULE_USES
}
!isEmpty(BAD_QT):error("Unknown module(s) in QT$$var_sfx: $$replace(BAD_QT, _private$, -private)")
!isEmpty(var_sfx): break()
var_sfx = _PRIVATE
}
!isEmpty(using_private_headers):!no_private_qt_headers_warning:!build_pass {
message("This project is using private headers and will therefore be tied to this specific Qt module build version.")
message("Running this project against other versions of the Qt modules may crash at any arbitrary point.")
message("This is not a bug, but a result of using Qt internals. You have been warned!")
}
!no_qt_rpath:!static:qtConfig(rpath):!qtConfig(static):\
contains(all_qt_module_deps, core) {
relative_qt_rpath:!isEmpty(QMAKE_REL_RPATH_BASE):contains(INSTALLS, target):\
isEmpty(target.files):isEmpty(target.commands):isEmpty(target.extra) {
# NOT the /dev property, as INSTALLS use host paths
QMAKE_RPATHDIR += $$relative_path($$[QT_INSTALL_LIBS], $$qtRelativeRPathBase())
} else {
QMAKE_RPATHDIR += $$[QT_INSTALL_LIBS/dev]
}
}
!isEmpty(QMAKE_LFLAGS_RPATHLINK):!qtConfig(static) {
# -rpath-link is used by the linker to find dependencies of dynamic
# libraries which were NOT specified on the command line.
# This means that paths of direct dependencies (QT & QT_PRIVATE)
# don't need to be listed, unlike their private dependencies' paths.
privdep = $$all_qt_module_deps
privdep -= $$resolve_depends(qt_module_deps, "QT.")
rpaths =
for(dep, privdep): \
rpaths += $$eval(QT.$${dep}.libs)
QMAKE_RPATHLINKDIR *= $$unique(rpaths)
}
# static builds: link qml import plugins into the target.
contains(all_qt_module_deps, qml): \
qtConfig(static):import_plugins:!host_build:!no_import_scan {
exists($$[QT_INSTALL_QML/get]): \
QMLPATHS *= $$[QT_INSTALL_QML/get]
# run qmlimportscanner
qtPrepareLibExecTool(QMLIMPORTSCANNER, qmlimportscanner, , system)
for (QMLPATH, QMLPATHS): \
IMPORTPATHS += -importPath $$system_quote($$QMLPATH)
# add resources to qmlimportscanner
for (RESOURCE, RESOURCES) {
defined($${RESOURCE}.files, var) {
# in case of a "struct", add the struct's files
base = $$RESOURCE.base
for (f, $$RESOURCE.files): SCANNERRESOURCES += "$$base/$$f"
} else {
# if the resource is a file, just add it
SCANNERRESOURCES += $$RESOURCE
}
}
!isEmpty(SCANNERRESOURCES) {
IMPORTPATHS += -qrcFiles
for (RESOURCE, SCANNERRESOURCES): \
IMPORTPATHS += $$absolute_path($$system_quote($$RESOURCE), $$_PRO_FILE_PWD_)
}
# message(run $$QMLIMPORTSCANNER $$_PRO_FILE_PWD_ $$IMPORTPATHS)
JSON = $$system($$QMLIMPORTSCANNER $$system_quote($$_PRO_FILE_PWD_) $$IMPORTPATHS)
parseJson(JSON, IMPORTS)| error("Failed to parse qmlimportscanner output.")
!isEmpty(IMPORTS._KEYS_) {
# add import plugins to LIBS line
for (key, IMPORTS._KEYS_) {
PATH = $$eval(IMPORTS.$${key}.path)
PLUGIN = $$eval(IMPORTS.$${key}.plugin)
!isEmpty(PATH):!isEmpty(PLUGIN): \
LIBS += $$PATH/$$QMAKE_PREFIX_STATICLIB$${PLUGIN}$$qtPlatformTargetSuffix().$$QMAKE_EXTENSION_STATICLIB
}
# create qml_plugin_import.cpp
IMPORT_FILE_CONT = \
"// This file is autogenerated by qmake. It imports static plugin classes for" \
"// static plugins used by QML imports." \
"$${LITERAL_HASH}include <QtPlugin>"
for (key, IMPORTS._KEYS_) {
PLUGIN = $$eval(IMPORTS.$${key}.plugin)
CLASSNAME = $$eval(IMPORTS.$${key}.classname)
!isEmpty(PLUGIN) {
!isEmpty(CLASSNAME) {
!contains(ADDED_IMPORTS, $$PLUGIN) {
ADDED_IMPORTS += $$PLUGIN
IMPORT_FILE_CONT += "Q_IMPORT_PLUGIN($$CLASSNAME)"
}
} else {
error("Plugin $$PLUGIN is missing a classname entry, please add one to the qmldir file.")
}
}
}
TARGET_BASENAME = $$lower($$basename(TARGET))
TARGET_BASENAME ~= s/\s/_/g
QML_IMPORT_CPP = $$OUT_PWD/$${TARGET_BASENAME}_qml_plugin_import.cpp
write_file($$QML_IMPORT_CPP, IMPORT_FILE_CONT)|error()
GENERATED_SOURCES += $$QML_IMPORT_CPP
QMAKE_DISTCLEAN += $$QML_IMPORT_CPP
}
}