Details
-
Bug
-
Resolution: Done
-
Not Evaluated
-
None
-
5.0.0
-
None
-
a97b909363b28ce20c753558ba730e759b9ed285, 6b497734df0c4f13f6b7185801fc69ce680c698c, 619e567e8f4cca6f4f97128057302f820ec03d43
Description
Many autotests for qtdeclarative are currently embedding the path of the source code into the binary at compile time (via _FILE_ or SRCDIR), and using this to find testdata.
This makes it unfeasible to copy the test and its data onto a device and run it there. The test will look for its testdata at whatever path the source code happened to be located on, on the machine doing the compilation.
The suggested method to fix the problem is:
1. modify the test to find its data relative to the test binary instead - e.g. QCoreApplication::applicationDirPath() gives the path to the directory containing the test executable
2. modify the test .pro file to make sure all the testdata is listed in a DEPLOYMENT section
http://codereview.qt-project.org/5578 is an example of a fix for one test.
About the DEPLOYMENT variable:
- the .files attribute refers to one or more files or directories which need to be deployed alongside the test. (for directories, it means the entire content of that directory is deployed)
- the .path attribute is the path where the testdata should be located, relative to the directory containing the test binary. (probably just `.' in the majority of cases)
- the DEPLOYMENT variable is a no-op for a typical desktop build, so it doesn't need to be scoped specifically for device builds.
- a lot of the tests already contain an attempt to fix this problem specifically for symbian, but it is probably incorrect and crufty.
An example to clarify. For the way we are packaging tests, given a test `qdeclarativepixmapcache', and this DEPLOYMENT section:
importFiles.files = data importFiles.path = . DEPLOYMENT += importFiles
... we will ultimately end up with the files:
/usr/lib/qt5declarative-tests/tst_qdeclarativepixmapcache/tst_qdeclarativepixmapcache # the test binary /usr/lib/qt5declarative-tests/tst_qdeclarativepixmapcache/data # the `data' directory, copied recursively from source tree
It's somewhat possible to test if it's working correctly on a desktop build by compiling the test, then moving the test and binary to some other location and checking if it still works.
There may be a few special cases which are not so easy to handle, e.g. tst_examples really expects the source tree to be present.