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

61 lines
1.7 KiB
Plaintext
Raw Normal View History

mark a bunch of features as internal Change-Id: I5ad28827ff317985414e859263af85ceec31207c Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2012-12-11 21:08:15 +00:00
#
# W A R N I N G
# -------------
#
# This file is not part of the Qt API. It exists purely as an
# implementation detail. It may change from version to version
# without notice, or even be removed.
#
# We mean it.
#
beef up qt_plugin.prf it now defines the DESTDIR and creates an INSTALLS rule. Change-Id: I15a462ccad9acbe3521c352fa98327825dc27c05 Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2012-10-24 12:00:12 +00:00
load(qt_build_paths)
isEmpty(PLUGIN_TYPE): error("PLUGIN_TYPE (plugins/ subdirectory) needs to be defined.")
Made qpluginbase.pri into a feature profile. This enables other modules to use it without having access to the QtBase sources. Change-Id: I0a588b2e14ca88fa068c7c2bcc69ff669444f6c6 Task: QTBUG-19585 Reviewed-on: http://codereview.qt.nokia.com/237 Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com> Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
2011-05-27 08:10:36 +00:00
TEMPLATE = lib
beef up qt_plugin.prf it now defines the DESTDIR and creates an INSTALLS rule. Change-Id: I15a462ccad9acbe3521c352fa98327825dc27c05 Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2012-10-24 12:00:12 +00:00
CONFIG += plugin
DESTDIR = $$MODULE_BASE_OUTDIR/plugins/$$PLUGIN_TYPE
Made qpluginbase.pri into a feature profile. This enables other modules to use it without having access to the QtBase sources. Change-Id: I0a588b2e14ca88fa068c7c2bcc69ff669444f6c6 Task: QTBUG-19585 Reviewed-on: http://codereview.qt.nokia.com/237 Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com> Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
2011-05-27 08:10:36 +00:00
introduce tool_plugin CONFIG flag while plugins for libraries need to follow the -debug-and-release switch, plugins for tools must follow the single-config approach of tools. Change-Id: I8a79e98034d2ff8b5d4e6191a9143c9472a5aa02 Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2012-10-24 12:03:47 +00:00
tool_plugin {
!build_pass:contains(QT_CONFIG, build_all): CONFIG += release
} else:if(win32|mac):!macx-xcode {
Do not add debug/release to QMAKE_CONFIG. Let module system enable them This solved QTBUG-26111 in which qtjsbackend gets built with an incomplete framework on Mac OSX. This was traced back to commit 6a6fd56e662b2c1a581727f7ec44d5bd60913ad4 which moved QMAKE_CONFIG values from .qmake.cache to mkspecs/qmodule.pri. Since qtjsbackend contains config tests it creates its own .qmake.cache which was previously masking this issue. QMAKE_CONFIG incorrectly contained debug for debug_and_release builds even though debug and release are already present in the CONFIG variable in mkspecs/qconfig.pri. The changes to configure prevent CONFIG in qmodule.pri from containing debug and release variables and ensure that QT_CONFIG contains build_all and debug_and_release if appropriate. Configure.app is also adjusted to match this behaviour. The other part of the change is to qt_module_config.prf and qt_plugin.prf. These changes take care of populating CONFIG with the appropriate debug_and_release and build_all variables depending upon what is present in QT_CONFIG. This ensures that the Qt modules and plugins get built with the same configuration as qtbase. The special handling for the qcocoa QPA plugin ensures that it is built in release mode only to preserve the behaviour introduced by commit 5603f94eaa538dbe28fc426065d65a27799adedc. Task-number: QTBUG-26111 Change-Id: I6f65aba50709e1b2431b8b4411ff30a06f7d8aed Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
2012-06-12 11:30:13 +00:00
contains(QT_CONFIG, debug_and_release):CONFIG += debug_and_release
contains(QT_CONFIG, build_all):CONFIG += build_all
}
Made qpluginbase.pri into a feature profile. This enables other modules to use it without having access to the QtBase sources. Change-Id: I0a588b2e14ca88fa068c7c2bcc69ff669444f6c6 Task: QTBUG-19585 Reviewed-on: http://codereview.qt.nokia.com/237 Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com> Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
2011-05-27 08:10:36 +00:00
contains(QT_CONFIG, reduce_exports):CONFIG += hide_symbols
Configure: Set separate_debug_info for all modules separate_debug_info was previously stored in .qmake.cache, and therefore only affected qtbase. Store it as a QT_CONFIG setting instead, and add it to CONFIG for all Qt plugins and modules. Change-Id: I940c8cb30f1c42c85f4d0342e6a482f20677ff04 Reviewed-on: http://codereview.qt.nokia.com/2975 Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com> Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
2011-08-15 13:36:08 +00:00
contains(QT_CONFIG, separate_debug_info):CONFIG += separate_debug_info
contains(QT_CONFIG, separate_debug_info_nocopy):CONFIG += separate_debug_info_nocopy
configure: Auto-detect and enable C++11 support if available Enabling support for C++11 adds CONFIG+=c++11 to the Qt build. Projects using Qt can check for C++11 support using contains(QT_CONFIG, c++11) in their .pr[iof] files. The QMAKE_CXXFLAGS_CXX11 and QMAKE_LFLAGS_CXX11 qmake varibles contain any arguments the compiler needs to enable C++11. CONFIG+=c++11 adds these arguments to the build. Support for clang, g++, and the Intel C++ Compiler for Linux are included in this commit. Change-Id: Id77f86d7ad4d5c740b890446a40b105879a0d327 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
2012-05-29 05:10:09 +00:00
contains(QT_CONFIG, c++11):CONFIG += c++11
Made qpluginbase.pri into a feature profile. This enables other modules to use it without having access to the QtBase sources. Change-Id: I0a588b2e14ca88fa068c7c2bcc69ff669444f6c6 Task: QTBUG-19585 Reviewed-on: http://codereview.qt.nokia.com/237 Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com> Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
2011-05-27 08:10:36 +00:00
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, static):CONFIG += static
else:CONFIG += shared
Fix installation of plugin module .pris in static Qt builds When building Qt static, plugins get module .pri file, but those files do not get installed in Windows. This is because both .pri generation and install target statements are scoped with !build_pass, which means Makefile.Debug and Makefile.Release do not get install_pritarget target. Fixed by doing only the .pri generation in !build_pass scope. Task-number: QTBUG-28606 Change-Id: If3f49b578af1d9171a8bce67793ecb3f902a6da8 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Mark Brand <mabrand@mabrand.nl>
2012-12-14 09:51:28 +00:00
static {
Fix module pri file name for static plugins Since QTPLUGIN variable values are used to locate both the plugin library and the module pri file, those must match. Therefore generate module pri file name using the TARGET of the plugin rather than the pro file name. Change-Id: I9ec6f2a087ba3b3cecf7034c8a28b31df155cd97 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2012-12-07 09:46:43 +00:00
isEmpty(MODULE): MODULE = $$basename(TARGET)
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
MODULE_PRI = $$MODULE_QMAKE_OUTDIR/mkspecs/modules/qt_plugin_$${MODULE}.pri
Fix installation of plugin module .pris in static Qt builds When building Qt static, plugins get module .pri file, but those files do not get installed in Windows. This is because both .pri generation and install target statements are scoped with !build_pass, which means Makefile.Debug and Makefile.Release do not get install_pritarget target. Fixed by doing only the .pri generation in !build_pass scope. Task-number: QTBUG-28606 Change-Id: If3f49b578af1d9171a8bce67793ecb3f902a6da8 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Mark Brand <mabrand@mabrand.nl>
2012-12-14 09:51:28 +00:00
!build_pass {
MODULE_PRI_CONT = \
"QT_PLUGIN.$${MODULE}.TYPE = $$PLUGIN_TYPE" \
"QT_PLUGIN.$${MODULE}.CLASS_NAME = $$PLUGIN_CLASS_NAME"
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
Fix installation of plugin module .pris in static Qt builds When building Qt static, plugins get module .pri file, but those files do not get installed in Windows. This is because both .pri generation and install target statements are scoped with !build_pass, which means Makefile.Debug and Makefile.Release do not get install_pritarget target. Fixed by doing only the .pri generation in !build_pass scope. Task-number: QTBUG-28606 Change-Id: If3f49b578af1d9171a8bce67793ecb3f902a6da8 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Mark Brand <mabrand@mabrand.nl>
2012-12-14 09:51:28 +00:00
write_file($$MODULE_PRI, MODULE_PRI_CONT)|error("Aborting.")
}
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
pritarget.path = $$[QT_HOST_DATA]/mkspecs/modules
pritarget.files = $$MODULE_PRI
INSTALLS += pritarget
}
beef up qt_plugin.prf it now defines the DESTDIR and creates an INSTALLS rule. Change-Id: I15a462ccad9acbe3521c352fa98327825dc27c05 Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2012-10-24 12:00:12 +00:00
target.path = $$[QT_INSTALL_PLUGINS]/$$PLUGIN_TYPE
INSTALLS += target
TARGET = $$qtLibraryTarget($$TARGET)
Made qpluginbase.pri into a feature profile. This enables other modules to use it without having access to the QtBase sources. Change-Id: I0a588b2e14ca88fa068c7c2bcc69ff669444f6c6 Task: QTBUG-19585 Reviewed-on: http://codereview.qt.nokia.com/237 Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com> Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
2011-05-27 08:10:36 +00:00
load(qt_targets)
wince*:LIBS += $$QMAKE_LIBS_GUI
Make plugin linking fail if some references aren't present It's better to fail at linking time than to try and figure out later why QPluginLoader refuses to load the plugin. Change-Id: I439bad9dcdbfff9f76efe40381fd7ccfffe738bc Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com> Reviewed-by: Donald Carr <donald.carr@nokia.com> Reviewed-by: Girish Ramakrishnan <girish.1.ramakrishnan@nokia.com>
2011-12-23 12:47:15 +00:00
QMAKE_LFLAGS += $$QMAKE_LFLAGS_NOUNDEF
Reference in New Issue Copy Permalink