AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
d441f6bba7
qt5base-lts/tests/auto/tools/moc/moc.pro

52 lines
2.0 KiB
Prolog
Raw Normal View History

all remaining tests: eliminated usage of qttest_p4.prf qttest_p4.prf was added as a convenience for Qt's own autotests in Qt4. It enables various crufty undocumented magic, of dubious value. Stop using it, and explicitly enable the things from it which we want. Change-Id: I02fe27b2c1800f929250fa8694ca2976c9661a12 Reviewed-by: Jason McDonald <jason.mcdonald@nokia.com>
2011-10-25 04:42:16 +00:00
CONFIG += testcase
TARGET = tst_moc
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
#exists(/usr/include/boost/spirit.hpp) {
# message("including boost headers in test")
# DEFINES += PARSE_BOOST
# # need to add explicitly so that it ends up in moc's search path
# INCLUDEPATH += /usr/include
#}
INCLUDEPATH += testproject/include testproject
cross_compile: DEFINES += MOC_CROSS_COMPILED
HEADERS += using-namespaces.h no-keywords.h task87883.h c-comments.h backslash-newlines.h oldstyle-casts.h \
slots-with-void-template.h qinvokable.h namespaced-flags.h trigraphs.h \
escapes-in-string-literals.h cstyle-enums.h qprivateslots.h gadgetwithnoenums.h \
dir-in-include-path.h single_function_keyword.h task192552.h task189996.h \
moc: parse classes that use Q_DECL_FINAL|final|sealed This only works with the C++11 contextual keyword directly, the MSVC equivalent 'sealed', or the Qt define for it. While this isn't a problem for syncqt, being an internal tool, moc should eventually be able to parse user code using local C++11-final-wrapping macros. For this, I guess moc would have to be taught to expand macros in code and not just test #if clauses, potentially driven by something like #pragma qt-moc expand-this #define MY_FINAL_CLASS final but that's something for someone more intimately familiar with moc's source than I am. Change-Id: Id6aec961a881e8d5a9b76a7fc8e1c02c71913f64 Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
2012-03-05 16:55:59 +00:00
task234909.h task240368.h pure-virtual-signals.h cxx11-enums.h \
cxx11-final-classes.h \
moc: test slots marked final/override in various ways While writing the test, I found that moc doesn't yet support volatile slots. I left the tests in, commented, for a time when it does. Change-Id: Ib5fa00b25600618aedcc66739630054f3c879b99 Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
2012-07-10 16:08:18 +00:00
cxx11-explicit-override-control.h \
Generate includes for Qt containers used as auto-metatypes. Otherwise the containers might be forward declared in the moc file, and when the moc file is compiled in a standalone translation unit, the full definition of it would not be available. This results in odd compile errors, so instead generate the includes if required. Change-Id: Ie01c5a5d45314daad0b00dec03b3e1e18cdbae64 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Volker Krause <volker.krause@kdab.com> Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
2012-09-03 10:55:38 +00:00
forward-declared-param.h \
Fix moc stumbling over gcc __attribute__ extensions Reported by David Faure. In KDE a DEPRECATED macro gets defined in a header file created by cmake. The define is not guarded with #if Q_CC_GNU or similar because at cmake time the compiler is determined. Therefore moc suddenly sees this gcc specific token and stumbles over it. This patch simply defines an empty __attribute__ macro that will expand to nothing and thus become invisible to moc's "C++ parser" after the pre-processing. Change-Id: I4448b9ac3f72b6334e32b27484401fb0fca23a0c Reviewed-by: David Faure <faure@kde.org> Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
2012-10-01 09:57:53 +00:00
parse-defines.h \
moc: add -M<key=value> to ease static qml plugin linking A module plugin in qml belongs to a URI/namespace. This uri is resolved run-time by QtDeclarative by knowing the path of the qmldir that references the plugin. For static plugins this becomes a problem, since we lost the information regarding which plugin belongs to which qmldir, since a static plugin has no file path. To avoid pushing the responsibility of clarifying this onto the application developer, it is better to embed this information into the meta data of the plugins themselves. Since this information can be resolved by the build system, a new option to moc has been added: -M<key=value> that will let you add meta tags to the meta data from the command line to each class that has an IID specified. For the URI case, we can then e.g do: -Muri=QtQuick.Controls -Muri=QtQuick.Controls.Private Change-Id: I81a156660148fc94db6f3cac0473e9e1c8458c58 Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
2013-08-20 07:02:17 +00:00
function-with-attributes.h \
Test that Qt tools can handle ' as a digit separator. Change-Id: I0a3446d02184989c32367e66d4f5d9e464a56ec6 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2013-10-25 15:00:17 +00:00
plugin_metadata.h \
Fix erroneous exclusion of classes from related meta objects in moc Assume an unrelated class that declares an enum and uses Q_ENUMS. Consider then a class that uses UnrelatedClass::Enum as a Q_PROPERTY. We used to include UnrelatedClass in the primary class's related meta objects, in order to support use-cases like obj->setProperty("enumProperty", "ValueOfEnumAsString"); If however moc happens to see Q_DECLARE_METATYPE(UnrelatedClass::Enum), then it would exclude it from the related meta objects, which would silently break the string based enum value conversion. This was meant as an optimization, but it isn't apparent to the developer why sometimes the string conversion would work and sometimes not (depending on whether somebody declares that macro). This also becomes visible in QML, which relies on the same embedded type information for enum assignments. This patch removes that check in moc's code generator and cleans up the code a little. However always including the prefix of Q_PROPERTY(SomePrefix::Enum ...) is not correct either, because it may be that SomePrefix is a namespace, which would cause compilation issues. Therefore we limit the inclusion of related meta objects only to Q_OBJECT decorated classes the moc has seen, and for these we save the fully qualified name in the related meta objects array (for QTBUG-2151). While this patch makes the previous workaround for namespace issues by using a Q_DECLARE_METATYPE not workable anymore, by saving the fully qualified name we are making a hopefully sufficient effort to not require a workaround in the first place. There's always the new workaround of fully qualifying the type in Q_PROPERTY. One side-effect of this change is that in the autoPropertyMetaTypeRegistration test of tst_moc, the CustomQObject for Q_PROPERTY(CustomQObject::Number enumValue ...) is now a related meta object, and therefore when querying for the type of this property via QMetaProperty::userType(), we are now aware of this being an enum and try to resolve CustomQObject::Number via QMetaType::type(qualfiedName). As there is no guarantee for this to succeed, we must now also do what is done in the non-enum code path in ::userType(), which is to call the moc generated type registration function. Task-number: QTBUG-33577 Task-number: QTBUG-2151 Change-Id: Ibf20e7421cba464c558a25c76a7e1eef002c6cff Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
2013-12-12 09:50:00 +00:00
single-quote-digit-separator-n3781.h \
Fix regression in property handling with enums from gadgets When declaring a Q_PROPERTY(SomeType::SomeEnum foo ...) and SomeType is not a QObject but a gadget, then we must still include SomeType's meta object in the list of related meta objects. Task-number: QTBUG-35657 Change-Id: I46195140cb5d180c4f03bb1fe06a876e3fe11267 Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
2013-12-23 14:16:08 +00:00
related-metaobjects-in-namespaces.h \
qtbug-35657-gadget.h \
moc: Don't link to inexistent parent staticMetaObject Contrarily to Q_OBJECTs, Q_GADGETs are not guaranteed to descend from a Q_GADGET. Here, we ensure that if the first superclass is a Q_GADGET, then the derived class will be treated as one. This allows gaps in the Q_GADGET hierarchy while preventing from trying to link to the inexistent staticMetaObject if there's no such ancestor. Change-Id: If10fb952e23655102a425bb18fe8babaf447a47f Reviewed-by: Olivier Goffart <ogoffart@woboq.com> Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
2015-01-12 14:55:13 +00:00
non-gadget-parent-class.h grand-parent-gadget-class.h \
Fix lack of deterministic behavior in moc. Moc should check full scope of any related objects or gadget when it constructs extra data. Change-Id: Ibd1b607a389cd4e788c0916984464cd9103d9c59 Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
2014-01-17 17:25:50 +00:00
related-metaobjects-in-gadget.h \
Parse namespaces only for current file, add Q_NAMESPACE support to qmake Parsing the other files will (re)generate the same metaobject info in two places Change-Id: I8984ed30751a7587de870f55dd427f067d1b2495 Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
2016-08-23 19:32:11 +00:00
related-metaobjects-name-conflict.h \
moc: Add support for C++17 nested namespaces (N4230) [ChangeLog][moc] Added Support for C++17 nested namespaces Change-Id: Ib83fc5bf48f66546fa97b49710582fbf9c984503 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2017-03-08 10:52:37 +00:00
namespace.h cxx17-namespaces.h
moc: parse classes that use Q_DECL_FINAL|final|sealed This only works with the C++11 contextual keyword directly, the MSVC equivalent 'sealed', or the Qt define for it. While this isn't a problem for syncqt, being an internal tool, moc should eventually be able to parse user code using local C++11-final-wrapping macros. For this, I guess moc would have to be taught to expand macros in code and not just test #if clauses, potentially driven by something like #pragma qt-moc expand-this #define MY_FINAL_CLASS final but that's something for someone more intimately familiar with moc's source than I am. Change-Id: Id6aec961a881e8d5a9b76a7fc8e1c02c71913f64 Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
2012-03-05 16:55:59 +00:00
Remove references to obsolete platforms ultrix and reliant have not seen a release since 1995. dgux not since 2001. bsdi not since 2003. irix not since 2006. osf not since 2010. dynix... unclear, but no later than 2002. symbian needs no mention. All considered obsolete, all gone. sco and unixware are effectively obsolete. Remove them until someone expresses a real need. Change-Id: Ia3d9d370016adce9213ae5ad0ef965ef8de2a3ff Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2017-10-01 01:19:36 +00:00
if(*-g++*|*-icc*|*-clang*|*-llvm):!win32-*: HEADERS += os9-newlines.h win-newlines.h
moc: Support the '$' character as an identifier Both gcc and clang allow the use of '$' in their identifiers as an extension. moc should not throw a parse error if there is one in the file. Instead, consider '$' as valid in identifiers. Task-number: QTBUG-22720 Change-Id: I8be3a52429c0db5b7e8308b8f4fe475d3d3994bf Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
2013-03-01 14:06:33 +00:00
if(*-g++*|*-clang*): HEADERS += dollars.h
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
SOURCES += tst_moc.cpp
Clean up the moc "no-keywords" test We can use the QT_LIB_FOO #defines instead of our own WITH_FOO ones to determine if a library is available. Also, it doesn't currently make sense to refer to libraries which are not part of qtbase here. We might add that in the future, but QtScript (being deprecated) is probably not the first one we should add. Change-Id: I7f2397ca5499ba6003088478161182e960e815fb Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
2017-01-09 10:39:46 +00:00
QT = core testlib
qtHaveModule(dbus): QT += dbus
qtHaveModule(concurrent): QT += concurrent
qtHaveModule(network): QT += network
qtHaveModule(sql): QT += sql
moc: add -M<key=value> to ease static qml plugin linking A module plugin in qml belongs to a URI/namespace. This uri is resolved run-time by QtDeclarative by knowing the path of the qmldir that references the plugin. For static plugins this becomes a problem, since we lost the information regarding which plugin belongs to which qmldir, since a static plugin has no file path. To avoid pushing the responsibility of clarifying this onto the application developer, it is better to embed this information into the meta data of the plugins themselves. Since this information can be resolved by the build system, a new option to moc has been added: -M<key=value> that will let you add meta tags to the meta data from the command line to each class that has an IID specified. For the URI case, we can then e.g do: -Muri=QtQuick.Controls -Muri=QtQuick.Controls.Private Change-Id: I81a156660148fc94db6f3cac0473e9e1c8458c58 Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
2013-08-20 07:02:17 +00:00
# tst_Moc::specifyMetaTagsFromCmdline()
# Ensure that plugin_metadata.h are moc-ed with some extra -M arguments:
QMAKE_MOC_OPTIONS += -Muri=com.company.app -Muri=com.company.app.private
moc: Fix parsing of complex defines defined via command line Since now in Qt5 the moc does full macro substitution, it needs to handle the defines passed is command argument, even if they span over multiple tokens, or if they do not have any token. Example: moc '-DCOMPLEX=QVector<int>' '-DEMPTY=' foo.h [ChangeLog][moc] Fixed passing -D of a macro defined to something more complex than a single identifier. Task-number: QTBUG-33668 Change-Id: Ie8131de215f1659a24af4778d52ee40cda19759f Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
2013-09-25 19:36:15 +00:00
# Define macro on the command lines used in parse-defines.h
QMAKE_MOC_OPTIONS += "-DDEFINE_CMDLINE_EMPTY=" "\"-DDEFINE_CMDLINE_SIGNAL=void cmdlineSignal(const QMap<int, int> &i)\""
Reference in New Issue Copy Permalink