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

138 lines
5.3 KiB
Plaintext
Raw Normal View History

move moc, rcc and uic CONFIG additions to the respective qt modules they don't belong into the global scope Change-Id: I27a3de5f706392b3c4a84035521bc3b4e4055740 Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
2012-02-24 18:21:51 +00:00
CONFIG *= thread
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
#handle defines
win32 {
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
contains(QT_CONFIG, shared) {
# this variable is read by qmake in qmake/generators/win32/msvc_vcproj.cpp
# function VcprojGenerator::initDeploymentTool(), which contains some hardcoded
# library names (the ones that were static in Qt 4)
# it probably doesn't work anymore and should not be in this file
QMAKE_QT_DLL = 1
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(release, debug|release):DEFINES += QT_NO_DEBUG
Add a -force-asserts option to configure We have the following scenario: Either you build a release package without asserts, or a debug package with asserts. However, in embedded development, we need asserts also in release packages. This flag allows you to build a release package, but Q_ASSERTs still fire. Change-Id: Icd1dd4dd63c3cafecf515b40741263d902ad42d1 Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2011-11-11 10:21:52 +00:00
contains(QT_CONFIG, force_asserts):DEFINES += QT_FORCE_ASSERTS
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
no_keywords:DEFINES += QT_NO_KEYWORDS
plugin { #Qt plugins
static:DEFINES += QT_STATICPLUGIN
DEFINES += QT_PLUGIN
# Triggers both on Qt being configured with -arch boundschecker,
# and if you qmake CONFIG+=boundchecker on your plugin project
boundschecker|contains(QT_CONFIG,boundschecker) {
# This option is added for plugins when Qt is configured for Boundschecker,
# since we want Boundschecker to not instrument the qt_plugin_query_verification_data
# function, as we call that function without the plugin's dependent DLLs, thus
# Boundscheckers instrumentation will fail. The function only returns a const char *,
# so no instrumentation is really needed on that function anyways.
QMAKE_CFLAGS += /nmignore:*:qt_plugin_query_verification_data
QMAKE_CXXFLAGS += /nmignore:*:qt_plugin_query_verification_data
}
}
Enable forcing generation of static plugin imports Using some modules requires importing static plugins also for shared libraries (namely QtAxServer), so provided a way to force plugin imports even for non-applications using force_import_plugins MODULE_CONFIG value. This required moving the plugin handling after qtAddModules calls in qt.prf. Task-number: QTBUG-28215 Change-Id: Id6bb92ed7c078cc8c54538ddc9bb8e8ad316f277 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2012-12-20 08:05:29 +00:00
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
}
Pro-file level support for importing plugins for static Qt builds Platform plugin is needed always when gui is linked to an application. This is tedious to do manually for static builds, so provide support for generating a source file that imports static plugins for application projects. "CONFIG += import_plugins" statement in application .pro file will generate required import statements for all plugins specified with QTPLUGIN variable. The plugin class names are found from plugin's module pri generated automatically when plugin is built, as long as the plugin specifies the PLUGIN_CLASS_NAME in the plugin .pro file before loading qt_plugin.prf. Task-number: QTBUG-28131 Change-Id: I19f8ea48a3c1e9b5c81f4399c4b5d439a6d4bea1 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2012-12-10 13:56:29 +00:00
Enable forcing generation of static plugin imports Using some modules requires importing static plugins also for shared libraries (namely QtAxServer), so provided a way to force plugin imports even for non-applications using force_import_plugins MODULE_CONFIG value. This required moving the plugin handling after qtAddModules calls in qt.prf. Task-number: QTBUG-28215 Change-Id: Id6bb92ed7c078cc8c54538ddc9bb8e8ad316f277 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2012-12-20 08:05:29 +00:00
unset(using_privates)
qtAddModules(QT, LIBS)
qtAddModules(QT_PRIVATE, LIBS_PRIVATE)
!isEmpty(using_privates):!auto_use_privates:!no_private_qt_headers_warning:if(!debug_and_release|!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!")
}
fix lack of rpath-link when using modules from final location if the libraries are in a non-standard location, but no rpath is used, rpath-link is needed. this is often the case for non-prefix builds (which have no forwarding pris any more). as we cannot store absolute paths in the final pris, we need to store the module names, and resolve them only at use time. Change-Id: I1538b5d531611c76a2d7058a3b2ff683bdcbe427 Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2013-02-01 16:30:31 +00:00
qtAddRpathLink($$QT $$QT_PRIVATE)
Enable forcing generation of static plugin imports Using some modules requires importing static plugins also for shared libraries (namely QtAxServer), so provided a way to force plugin imports even for non-applications using force_import_plugins MODULE_CONFIG value. This required moving the plugin handling after qtAddModules calls in qt.prf. Task-number: QTBUG-28215 Change-Id: Id6bb92ed7c078cc8c54538ddc9bb8e8ad316f277 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2012-12-20 08:05:29 +00:00
wince*:static:gui {
QTLIB += qmenu_wce.res
}
QT_PLUGIN_VERIFY = DEPLOYMENT_PLUGIN
Pro-file level support for importing plugins for static Qt builds Platform plugin is needed always when gui is linked to an application. This is tedious to do manually for static builds, so provide support for generating a source file that imports static plugins for application projects. "CONFIG += import_plugins" statement in application .pro file will generate required import statements for all plugins specified with QTPLUGIN variable. The plugin class names are found from plugin's module pri generated automatically when plugin is built, as long as the plugin specifies the PLUGIN_CLASS_NAME in the plugin .pro file before loading qt_plugin.prf. Task-number: QTBUG-28131 Change-Id: I19f8ea48a3c1e9b5c81f4399c4b5d439a6d4bea1 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2012-12-10 13:56:29 +00:00
contains(QT_CONFIG, static) {
QT_PLUGIN_VERIFY += QTPLUGIN
Enable forcing generation of static plugin imports Using some modules requires importing static plugins also for shared libraries (namely QtAxServer), so provided a way to force plugin imports even for non-applications using force_import_plugins MODULE_CONFIG value. This required moving the plugin handling after qtAddModules calls in qt.prf. Task-number: QTBUG-28215 Change-Id: Id6bb92ed7c078cc8c54538ddc9bb8e8ad316f277 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2012-12-20 08:05:29 +00:00
force_import_plugins|contains(TEMPLATE, .*app) {
Generalize the check for gui in static plugin import generation Generalize the check for gui by checking for needs_qpa_plugin CONFIG value instead, which gui adds to MODULE_CONFIG. Task-number: QTBUG-28215 Change-Id: I5834a3f81e5c3868ee1a3fa405ebc6410db1f900 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2012-12-20 08:07:20 +00:00
needs_qpa_plugin:import_qpa_plugin {
Automatically import plugins in all applications with static Qt Since all gui applications already need some QPA plugin added, we might as well add the default plugin and generate the code to import the plugins automatically. User can opt out from the automation by removing relevant items from CONFIG variable: link_qpa_plugin or import_plugins. Task-number: QTBUG-28131 Change-Id: Ic171c363464c099143374d3e39bcc28f6edf73d2 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2012-12-11 14:02:45 +00:00
qpa_minimal_plugin: \
QTPLUGIN += qminimal
else: \
QTPLUGIN += $$QT_DEFAULT_QPA_PLUGIN
Add QT_DEFAULT_QPA_PLUGIN to generated qconfig.pri Configure will now generate QT_DEFAULT_QPA_PLUGIN qmake variable to specify the default QPA plugin. "CONFIG += qpa_default_plugin" statement in application .pro file will add the default QPA plugin into QTPLUGINS. "CONFIG += qpa_minimal_plugin" statement in application .pro file will add the minimal QPA plugin into QTPLUGINS. Task-number: QTBUG-28131 Change-Id: I12a241005f30b37467d783b50f0369b47e605e68 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2012-12-10 14:11:47 +00:00
}
Pro-file level support for importing plugins for static Qt builds Platform plugin is needed always when gui is linked to an application. This is tedious to do manually for static builds, so provide support for generating a source file that imports static plugins for application projects. "CONFIG += import_plugins" statement in application .pro file will generate required import statements for all plugins specified with QTPLUGIN variable. The plugin class names are found from plugin's module pri generated automatically when plugin is built, as long as the plugin specifies the PLUGIN_CLASS_NAME in the plugin .pro file before loading qt_plugin.prf. Task-number: QTBUG-28131 Change-Id: I19f8ea48a3c1e9b5c81f4399c4b5d439a6d4bea1 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2012-12-10 13:56:29 +00:00
import_plugins:!isEmpty(QTPLUGIN) {
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>"
for(IMPORT_PLUG, $$list($$unique(QTPLUGIN))) {
PLUG_CLASS = $$eval(QT_PLUGIN.$${IMPORT_PLUG}.CLASS_NAME)
!isEmpty(PLUG_CLASS): \
IMPORT_FILE_CONT += "Q_IMPORT_PLUGIN($$PLUG_CLASS)"
else: \
warning("Plugin class name could not be determined for $$IMPORT_PLUG plugin.")
}
IMPORT_CPP = $$OUT_PWD/$$lower($$basename(TARGET))_plugin_import.cpp
write_file($$IMPORT_CPP, IMPORT_FILE_CONT)|error("Aborting.")
SOURCES += $$IMPORT_CPP
QMAKE_DISTCLEAN += $$IMPORT_CPP
}
}
}
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
for(QT_CURRENT_VERIFY, $$list($$QT_PLUGIN_VERIFY)) {
for(QTPLUG, $$list($$lower($$unique($$QT_CURRENT_VERIFY)))) {
# 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.
let static plugins have "module" pri files ... and use them in qt.prf instead of (not) maintaining hand-coded lists. Change-Id: Ia21f7864eaf3ca92fa75f23876f71075d0521f4b Reviewed-by: Mark Brand <mabrand@mabrand.nl>
2012-10-24 13:02:08 +00:00
QT_PLUGINPATH = $$eval(QT_PLUGIN.$${QTPLUG}.TYPE)
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
# Generate the plugin linker line
target_qt:isEqual(TARGET, QTPLUG) {
warning($$TARGET cannot have a QTPLUGIN of $$QTPLUG)
} else {
simplify determination of static plugin link line qt_debug & qt_release are dead, so collapse the respective paths and use an existing function. Change-Id: Ie800be477186a6eab72682d367b24e83c3b9bbc0 Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2012-09-20 10:17:30 +00:00
QT_LINKAGE = -l$${QTPLUG}$$qtPlatformTargetSuffix()
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
}
# Only link against plugin in static builds
isEqual(QT_CURRENT_VERIFY, QTPLUGIN): {
make use of $$[FOO/get] properties this cleans up a lot of hacks supporting the build of qt, including the last bits of $QTDIR. Change-Id: Id119886ed8097967dad6cf86ebd4e71d90c42841 Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
2012-03-22 11:40:00 +00:00
!isEmpty(QT_PLUGINPATH): LIBS *= -L$$[QT_INSTALL_PLUGINS/get]/$$QT_PLUGINPATH
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
LIBS += $$QT_LINKAGE
# if the plugin is linked statically there is no need to deploy it
DEPLOYMENT_PLUGIN -= $$QT_CURRENT_VERIFY
}
isEqual(QT_CURRENT_VERIFY, DEPLOYMENT_PLUGIN):shared:wince*: {
QT_ITEM =
CONFIG(debug, debug|release): QT_ITEM = $${QTPLUG}d4.dll
else: QT_ITEM = $${QTPLUG}4.dll
make use of $$[FOO/get] properties this cleans up a lot of hacks supporting the build of qt, including the last bits of $QTDIR. Change-Id: Id119886ed8097967dad6cf86ebd4e71d90c42841 Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
2012-03-22 11:40:00 +00:00
eval(qt_additional_plugin_$${QTPLUG}.files = $$[QT_INSTALL_PLUGINS/get]/$${QT_PLUGINPATH}/$${QT_ITEM})
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
eval(qt_additional_plugin_$${QTPLUG}.path = $${QT_PLUGINPATH})
DEPLOYMENT *= qt_additional_plugin_$${QTPLUG}
}
}
}
Reference in New Issue Copy Permalink