path: root/src/modules/qt_testlib.pri
Commit message (Collapse)AuthorAgeFilesLines
* auto-generate module prisOswald Buddenhagen2012-06-191-16/+0
| | | | | Change-Id: I654428771034221ccf424be34d5d9c7764daf3b4 Reviewed-by: Joerg Bornemann <>
* testlib: add QFINDTESTDATA macro for finding testdata filesRohan McGovern2011-12-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Automated tests often need to load some data from external files. Currently, a wide variety of approaches for this have been used in Qt autotests, including: - embed the source directory into the test binary at compile time, and find the testdata relative to that; this fails when the source tree is no longer available (e.g. when the tests are deployed to a device). - use a path relative to the current working directory, and trust that the caller always sets the current working directory such that the testdata can be found; this fails when the caller uses a different working directory than expected. - use a path relative to QCoreApplication::applicationDirPath(); this fails when source tree != build tree (since testdata is not automatically copied into the build tree). - compile the files into the binary using the Qt resource system; this should work, but does not allow for testing of code which genuinely needs external files. It seems that there is not a simple method for determining the testdata path which can be reliably used in all circumstances, so various tests have reinvented the testdata location method in different ways. Therefore, this is a good candidate for an addition to the testlib API. The current implementation of QFINDTESTDATA is able to find testdata in all three of (build tree, install tree, source tree), in that order. Change-Id: Ib2fed860723ccf437240da3b00db22dfe1a6b56c Reviewed-by: Jason McDonald <>
* Updated Qt and QtBase module version number to 5.0.0Eckhart Koppen2011-05-131-3/+3
| | | | Updated version in qglobal.h as well as the module version itself
* Move private headers into versioned subdirectoryMarius Storm-Olsen2011-05-021-5/+5
| | | | | | | This will allow us to expose private headers in a controlled manner, and ensure that they are not used by accident. This also means that we internally will have to enable the private headers for the modules we wish to use in the project.
* Introduced the QT.<module>.plugins variable to module profiles.axis2011-04-271-0/+1
* Added QT.<module>.imports support to module profiles.axis2011-04-271-0/+1
* Make each module refer to its own bin/Marius Storm-Olsen2011-04-271-0/+1
| | | | | | | Since modules cannot rely on QtCore having a build directory, nor can they build the applications directly into $$[QT_INSTALL_BINS] each module needs their own bin/. Add this path to each module's pri file, so others can use their applications
* Extended module profiles.axis2011-04-271-0/+1
| | | | Each module now sets the QT_CONFIG variable itself.
* Add the private_includes path to the modules .pri fileLiang Qi2011-04-271-0/+1
* Add the source path to the modules .pri fileMarius Storm-Olsen2011-04-271-0/+1
* Remove the hardcode QT_CONFIG in those pri files.Liang Qi2011-04-271-2/+0
* Add module specific pris, and make syncqt create fwd includesMarius Storm-Olsen2011-04-271-0/+12
The module specific pris define the modules name version dependencies include paths lib paths additional CONFIGs and DEFINES They are located in the modules source directory, with fwd includes created in QtBase/mkspecs/modules build directory. The pris use QT_MODULE_INCLUDE_BASE QT_MODULE_LIB_BASE to specify the locations for includes and libs. These paths are normally based on QT_INSTALL_HEADERS QT_INSTALL_LIBS for installed modules, but overridden to the module's build directory by syncqt for the fwd included pris. The path of the pris must be specified in the sync.profile for syncqt to create the fwding pris in QtBase.