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

269 lines
11 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)
purge auto_use_privates module option it was introduced as a hack to simplify writing tests, but the change to make use of it was backed out of testlib and nobody seems to care. Change-Id: Icc86621b865276e86593afdb923247bbdca19d49 Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2013-10-21 14:16:57 +00:00
!isEmpty(using_privates):!no_private_qt_headers_warning:if(!debug_and_release|!build_pass) {
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
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
}
Resolve Qt module deps before determining if QML import scanner is needed The qtAddModules functions resolves deps internally, but doesn't affect the original QT and QT_PRIVATE variables. We need to pick up situations such as the user adding QT += quick, which implies QT += qml through the QtQuick module's dependecies. Change-Id: I14411dbea3e4f7402be404073a3fe8f18dbb165f Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-11-04 11:08:43 +00:00
qt_module_deps = $$QT $$QT_PRIVATE
qt_module_deps = $$replace(qt_module_deps, -private$, _private)
qt_module_deps = $$resolve_depends(qt_module_deps, "QT.")
automatically link plugins belonging to qt modules when building static apps the plugins already declare which modules they belong to. additionally, we allow plugins to declare which modules they "extend" - e.g., while the Quick accessibility plugin belongs to Gui's 'accessiblity' type, it makes no sense to link it unless Quick is actually linked. finally, it is possible to manually override the plugins which are linked for a particular type, by setting QTPLUGIN.<type> (to '-' if no plugins of this type should be linked at all). Task-number: QTBUG-35195 Change-Id: I8273d167a046eb3f3c1c584dc6e3798212a2fa31 Reviewed-by: Fawzi Mohamed <fawzi.mohamed@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2014-04-02 20:17:40 +00:00
# static builds: link qml import plugins into the app.
Resolve Qt module deps before determining if QML import scanner is needed The qtAddModules functions resolves deps internally, but doesn't affect the original QT and QT_PRIVATE variables. We need to pick up situations such as the user adding QT += quick, which implies QT += qml through the QtQuick module's dependecies. Change-Id: I14411dbea3e4f7402be404073a3fe8f18dbb165f Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-11-04 11:08:43 +00:00
contains(qt_module_deps, qml): \
make it possible to explicitly suppress the qml import scan if the user knows that no additional imports need to be linked, this can be used to optimize the build time. as it happens, it can also be used to fix the build of the qml tools themselves ... Change-Id: Id77aea1f20cabdc2e831540c61d8a4b8e85c040b Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2013-10-18 11:26:16 +00:00
contains(QT_CONFIG, static):contains(TEMPLATE, .*app):!host_build:!no_import_scan {
unbreak static qml imports again a) qmlimportscanner has no built-in -importPath, so it can't be omitted even for non-prefix builds, and b) the QMLPATHS variable is also used further down, so we can't just do away with it. amends a658fa40. Change-Id: I42a47a82fe13694fbac3c4a3962ebbe1d7e7865b Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2014-06-02 09:40:36 +00:00
!isEmpty(QTREPOS) {
for (qrep, QTREPOS): \
exists($$qrep/qml): \
QMLPATHS += $$qrep/qml
} else {
QMLPATHS += $$[QT_INSTALL_QML/get]
}
Static builds: Link QML plugins. Run qmlimportscanner, add found plugins to the LIBS line, generate qml_plugin_import.cpp. Change-Id: I6c6b927cceb36fa2dc405ad698f26d20398b33c8 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2013-09-10 14:25:32 +00:00
# run qmlimportscanner
qmlimportscanner: Ensure the correct variant is run qmlimportscanner is run as a $$system command (as opposed to as a makefile command) so specify it as such to qtPrepareTool and run it as such too. The distinction is important for MinGW-w64 static builds where it must be run via cmd.exe and not sh.exe. Change-Id: I0832d5138bff7f4fa1968646df28d2367ad062c2 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2014-03-10 23:31:16 +00:00
qtPrepareTool(QMLIMPORTSCANNER, qmlimportscanner, _SYS)
remove broken validation of QMLIMPORTSCANNER the variable may contain a complex command, so an exists() check is doomed to failure if the tool is built dynamically. also, the check is not really necessary: it failing indicates a bug in the qt build system, and we don't really need to complicate the code to deal with such corner cases. Change-Id: I2e6087dcc6dd4a4f70bdf739550276f364c880dd Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2013-10-18 11:20:41 +00:00
for (QMLPATH, QMLPATHS): \
IMPORTPATHS += -importPath $$QMLPATH
qmlimportscanner: Ensure the correct variant is run qmlimportscanner is run as a $$system command (as opposed to as a makefile command) so specify it as such to qtPrepareTool and run it as such too. The distinction is important for MinGW-w64 static builds where it must be run via cmd.exe and not sh.exe. Change-Id: I0832d5138bff7f4fa1968646df28d2367ad062c2 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2014-03-10 23:31:16 +00:00
#message(run $$QMLIMPORTSCANNER_SYS $$_PRO_FILE_PWD_ $$IMPORTPATHS)
JSON = $$system($$QMLIMPORTSCANNER_SYS $$_PRO_FILE_PWD_ $$IMPORTPATHS)
Static builds: Link QML plugins. Run qmlimportscanner, add found plugins to the LIBS line, generate qml_plugin_import.cpp. Change-Id: I6c6b927cceb36fa2dc405ad698f26d20398b33c8 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2013-09-10 14:25:32 +00:00
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)
qt.prf: add correct library version when using qmlimportscanner We need to add the correct suffix to the libs we add when running qmlimportscanner. Otherwise we will always add release versions of the libs instead of debug versions when generating debug builds. This in turn will confuse the xcode generator that will try to convert the libs in LIBS to native Xcode build variables. Change-Id: I4d9fab49ad9e644e9bfd06caf79fc084bde2a3b7 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
2013-11-01 14:21:45 +00:00
!isEmpty(PATH):!isEmpty(PLUGIN): LIBS *= -L$$PATH -l$${PLUGIN}$$qtPlatformTargetSuffix()
Static builds: Link QML plugins. Run qmlimportscanner, add found plugins to the LIBS line, generate qml_plugin_import.cpp. Change-Id: I6c6b927cceb36fa2dc405ad698f26d20398b33c8 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2013-09-10 14:25:32 +00:00
}
# 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.")
}
}
}
QML_IMPORT_CPP = $$OUT_PWD/$$lower($$basename(TARGET))_qml_plugin_import.cpp
write_file($$QML_IMPORT_CPP, IMPORT_FILE_CONT)|error("Aborting.")
SOURCES += $$QML_IMPORT_CPP
Delete qml_plugin_import.cpp file only during distclean For static builds of Qt Quick apps, qmake generates a qml_plugin_import.cpp file. Just like the Makefiles, it should be removed only for distclean, not in the clean step. This is what we do for non-qml plugins, too. Change-Id: I5a3f2e7d27c3ffd5161162a8a03e4dd9c9245af5 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2014-06-25 08:44:54 +00:00
QMAKE_DISTCLEAN += $$QML_IMPORT_CPP
Static builds: Link QML plugins. Run qmlimportscanner, add found plugins to the LIBS line, generate qml_plugin_import.cpp. Change-Id: I6c6b927cceb36fa2dc405ad698f26d20398b33c8 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2013-09-10 14:25:32 +00:00
# copy qml files. this part is platform spesific.
iOS (OSX): rework how to bundle QML import folders Before this patch, we would copy "$QTDIR/qml" directly into the bundle as "qml". This would cause problems if the user also tried to deploy qml files to a "qml" folder, or if any other file in the bundle ended up with the name "qml" (which is the case for QtDeclarative/tools/qml, where the executable is called "qml"). This patch will instead copy the contents of each import folder into QMAKE_QML_BUNDLE_PATH, which will default to "qt_qml" on iOS and "Resources/qt_qml" on OSX. We also change the implementation to use a post script rather then QMAKE_BUNDLE_DATA for two reasons: 1. Xcode does not like "copy build phases" to copy folders, only files (You cannot even create such a phase from Xcode, although it is possible to force it the way we create project.pbx. But this was error prone) 2. We need to strip away unneeded files from the bundle, like archives (which are linked in statically, not dlopened run-time). Using rsync lets us copy and strip in one operation. Change-Id: I7c2117f6cfbe11efdc272dff71adb0b1e619a5ff Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
2013-10-22 10:56:14 +00:00
mac {
osx {
# Note: user can override QMAKE_BUNDLE_QML from pro file to change target bundle path
isEmpty(QMAKE_QML_BUNDLE_PATH):QMAKE_QML_BUNDLE_PATH = "Resources/qt_qml"
qmlTargetPath = $$OUT_PWD/$${TARGET}.app/Contents/$$QMAKE_QML_BUNDLE_PATH
qtconfTargetPath = $$OUT_PWD/$${TARGET}.app/Contents/Resources/qt.conf
} else {
# iOS: flat bundle layout (no Contents/Resources)
isEmpty(QMAKE_QML_BUNDLE_PATH):QMAKE_QML_BUNDLE_PATH = "qt_qml"
qmlTargetPath = $CODESIGNING_FOLDER_PATH/$$QMAKE_QML_BUNDLE_PATH
qtconfTargetPath = $CODESIGNING_FOLDER_PATH/qt.conf
}
Static builds: Link QML plugins. Run qmlimportscanner, add found plugins to the LIBS line, generate qml_plugin_import.cpp. Change-Id: I6c6b927cceb36fa2dc405ad698f26d20398b33c8 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2013-09-10 14:25:32 +00:00
iOS (OSX): rework how to bundle QML import folders Before this patch, we would copy "$QTDIR/qml" directly into the bundle as "qml". This would cause problems if the user also tried to deploy qml files to a "qml" folder, or if any other file in the bundle ended up with the name "qml" (which is the case for QtDeclarative/tools/qml, where the executable is called "qml"). This patch will instead copy the contents of each import folder into QMAKE_QML_BUNDLE_PATH, which will default to "qt_qml" on iOS and "Resources/qt_qml" on OSX. We also change the implementation to use a post script rather then QMAKE_BUNDLE_DATA for two reasons: 1. Xcode does not like "copy build phases" to copy folders, only files (You cannot even create such a phase from Xcode, although it is possible to force it the way we create project.pbx. But this was error prone) 2. We need to strip away unneeded files from the bundle, like archives (which are linked in statically, not dlopened run-time). Using rsync lets us copy and strip in one operation. Change-Id: I7c2117f6cfbe11efdc272dff71adb0b1e619a5ff Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
2013-10-22 10:56:14 +00:00
# set import path in qt.conf to point to the bundeled qml:
Static builds: Link QML plugins. Run qmlimportscanner, add found plugins to the LIBS line, generate qml_plugin_import.cpp. Change-Id: I6c6b927cceb36fa2dc405ad698f26d20398b33c8 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2013-09-10 14:25:32 +00:00
QT_CONF_CONTENTS = \
"[Paths]" \
iOS (OSX): rework how to bundle QML import folders Before this patch, we would copy "$QTDIR/qml" directly into the bundle as "qml". This would cause problems if the user also tried to deploy qml files to a "qml" folder, or if any other file in the bundle ended up with the name "qml" (which is the case for QtDeclarative/tools/qml, where the executable is called "qml"). This patch will instead copy the contents of each import folder into QMAKE_QML_BUNDLE_PATH, which will default to "qt_qml" on iOS and "Resources/qt_qml" on OSX. We also change the implementation to use a post script rather then QMAKE_BUNDLE_DATA for two reasons: 1. Xcode does not like "copy build phases" to copy folders, only files (You cannot even create such a phase from Xcode, although it is possible to force it the way we create project.pbx. But this was error prone) 2. We need to strip away unneeded files from the bundle, like archives (which are linked in statically, not dlopened run-time). Using rsync lets us copy and strip in one operation. Change-Id: I7c2117f6cfbe11efdc272dff71adb0b1e619a5ff Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
2013-10-22 10:56:14 +00:00
"Imports = $$QMAKE_QML_BUNDLE_PATH" \
"Qml2Imports = $$QMAKE_QML_BUNDLE_PATH"
write_file("$$OUT_PWD/qt.conf", QT_CONF_CONTENTS)|error("Aborting.")
Static builds: Link QML plugins. Run qmlimportscanner, add found plugins to the LIBS line, generate qml_plugin_import.cpp. Change-Id: I6c6b927cceb36fa2dc405ad698f26d20398b33c8 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2013-09-10 14:25:32 +00:00
iOS (OSX): rework how to bundle QML import folders Before this patch, we would copy "$QTDIR/qml" directly into the bundle as "qml". This would cause problems if the user also tried to deploy qml files to a "qml" folder, or if any other file in the bundle ended up with the name "qml" (which is the case for QtDeclarative/tools/qml, where the executable is called "qml"). This patch will instead copy the contents of each import folder into QMAKE_QML_BUNDLE_PATH, which will default to "qt_qml" on iOS and "Resources/qt_qml" on OSX. We also change the implementation to use a post script rather then QMAKE_BUNDLE_DATA for two reasons: 1. Xcode does not like "copy build phases" to copy folders, only files (You cannot even create such a phase from Xcode, although it is possible to force it the way we create project.pbx. But this was error prone) 2. We need to strip away unneeded files from the bundle, like archives (which are linked in statically, not dlopened run-time). Using rsync lets us copy and strip in one operation. Change-Id: I7c2117f6cfbe11efdc272dff71adb0b1e619a5ff Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
2013-10-22 10:56:14 +00:00
# write qt.conf and copy each qml import dir into the bundle.
# But strip away archives and other files that are not needed:
!isEmpty(QMAKE_POST_LINK): QMAKE_POST_LINK += ";"
QMAKE_POST_LINK += \
"cp $$OUT_PWD/qt.conf $$qtconfTargetPath; " \
"test -d $$qmlTargetPath && rm -r $$qmlTargetPath; " \
"mkdir -p $$qmlTargetPath && " \
"for p in $$QMLPATHS; do" \
"rsync -r --exclude='*.a' --exclude='*.prl' --exclude='*.qmltypes' "
macx-xcode: QMAKE_POST_LINK += "$p/ $$qmlTargetPath; done"
else: QMAKE_POST_LINK += "\$\$p/ $$qmlTargetPath; done"
Static builds: Link QML plugins. Run qmlimportscanner, add found plugins to the LIBS line, generate qml_plugin_import.cpp. Change-Id: I6c6b927cceb36fa2dc405ad698f26d20398b33c8 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2013-09-10 14:25:32 +00:00
}
}
}
deprecate import_qpa_plugin and qpa_minimal_plugin they have been fully superseded by 4255ba40ab073afcf2a095b135883612859af4c2. Change-Id: If7ac14c8b7d3cf00fb0cb916036b62eb86c9cee0 Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2014-04-16 19:18:27 +00:00
!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
}
automatically link plugins belonging to qt modules when building static apps the plugins already declare which modules they belong to. additionally, we allow plugins to declare which modules they "extend" - e.g., while the Quick accessibility plugin belongs to Gui's 'accessiblity' type, it makes no sense to link it unless Quick is actually linked. finally, it is possible to manually override the plugins which are linked for a particular type, by setting QTPLUGIN.<type> (to '-' if no plugins of this type should be linked at all). Task-number: QTBUG-35195 Change-Id: I8273d167a046eb3f3c1c584dc6e3798212a2fa31 Reviewed-by: Fawzi Mohamed <fawzi.mohamed@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2014-04-02 20:17:40 +00:00
contains(TEMPLATE, .*app) {
autoplugs =
for (qtmod, qt_module_deps) {
for (ptype, QT.$${qtmod}.plugin_types) {
isEmpty(QTPLUGIN.$$ptype) {
for (plug, QT_PLUGINS) {
equals(QT_PLUGIN.$${plug}.TYPE, $$ptype) {
for (dep, QT_PLUGIN.$${plug}.EXTENDS) {
!contains(qt_module_deps, $$dep) {
plug =
break()
}
}
autoplugs += $$plug
}
}
} else {
plug = $$eval(QTPLUGIN.$$ptype)
!equals(plug, -): \
autoplugs += $$plug
}
}
}
manualplugs = $$QTPLUGIN
manualplugs -= $$autoplugs
QTPLUGIN -= $$manualplugs
!isEmpty(QTPLUGIN): \
warning("Redundant entries in QTPLUGIN: $$QTPLUGIN")
QTPLUGIN = $$manualplugs $$autoplugs
}
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
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) {
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 QTPLUGIN work in prefix builds for plugins outside qtbase this means creating forwarding pris also for plugins. unlike for qt modules, we don't actually populate the .PATH unless it we are making a prefix build (and thus expecting it to be outside the regular location). Change-Id: Id836821cddec8d5f53d0708ae001e8eaa13cc71b Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2014-04-04 14:49:26 +00:00
!isEmpty(QT_PLUGINPATH) {
plugpath = $$eval(QT_PLUGIN.$${QTPLUG}.PATH)
isEmpty(plugpath): \
plugpath = $$[QT_INSTALL_PLUGINS/get]
LIBS *= -L$$plugpath/$$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
}
WinRT: Basic global support Various global changes, primarily preprocessor flow, to support the WinRT platform. Change-Id: I3fa9cf91d5fb24019362e88fcf205e31b4f810b5 Reviewed-by: Andrew Knight <andrew.knight@digia.com>
2013-09-13 09:22:45 +00:00
isEqual(QT_CURRENT_VERIFY, DEPLOYMENT_PLUGIN):shared:if(wince*|winrt): {
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_ITEM =
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
debug: QT_ITEM = $${QTPLUG}d4.dll
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
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