This change adds a new command line option `qmake` to the tool which
allows the user to specify the qmake executable to be used. By default,
if that option is omitted, the behavior is unchanged (i.e. the tool first
searches for the `qmake` executable and - if this is not successful -
then for either `qmake-qt5` or `qmake-qt4`. If the new option is used,
no search takes place and instead the executable provided is used as-is.
This implements a part of the functionality as discussed in issue #94.
* Move testing logic from travis.yml to tests-ci.sh script
This way we can share this logic between travis CI and other systems
like for example a docker container.
* Move logic to create a testing environment to tests-environment.sh
As with the logic to execute the tests, this way we can share this logic
with other systems to tests linuxdeployqt.
* Install Qt also in tests-environment.sh
No reason to keep it separate from the rest as far as I know
* Wait until the X server is up and running
Otherwise we get into a racy situation.
* Add Dockerfile to create a testing container
This container tries to emulate the environment we have in travis-ci,
this way we can test whatever is failing on the CI locally.
The key with a space at the end does not seem to exists neither in my
testing environment (container reproducing current travis.yml file) nor
on my main system.
/usr/local is the canonical place to put self built applications and
libraries so it should be exlucded from the logic to detect distribution
shipped Qt.
probonopd
Piotr Krzemiński
Martin Höher
Àlex Fiestas