Allow for distributions that use "qmake-qt5" as the command

[probonopd]

This should help openSUSE which does not have update-alternatives:

• ldd the binary
• check for libQt5*
• if found, use qmake-qt5 if it is on the $PATH

[mhoeher]

Hi @probonopd,

just a suggestion: Instead of looking for alternative names under which qmake might be installed on a system, would it be possible to just allow passing the (relative or absolute) path to the qmake executable to be used to linuxdeployqt like:

# Provide absolute path to qmake:
linuxdeployqt --qmake $HOME/Qt/5.8/gcc_64/bin/qmake [...]

# Use system qmake which is named qmake-qt5:
linuxdeployqt --qmake qmake-qt5 [...]

This would be pretty much in line with what other tools do (e.g. setting the QT_QMAKE_EXECUTABLE variable in cmake to point it to the Qt version to be used).

This would also make using linuxdeployqt inside various build systems a bit easier (I encountered this issue when using the tool from within cmake, where I had to modify the environment of the tool invocation to have it use the right Qt version - having a simple option would definitely ease things).

Thanks for considering :-)

[probonopd]

Hi @mhoeher, thanks for this suggestion. Do the other *deployt tools use --qmake or QT_QMAKE_EXECUTABLE or both? I'd like to make it as consistent to the existing other tools as possible.

[mhoeher]

Hi @probonopd,

the tool I referred to is cmake, which is a build tool itself. It can be used instead of qmake (e.g. KDE is using it as default build tool). cmake in turn uses qmake to get information about the Qt installation to use for building. Hence, to change the Qt installation you want to use, you point cmake to another qmake via the QT_QMAKE_EXECUTABLE variable.

For linuxdeployqt I guess it would be better to add an argument instead of introducing the notion of "variables" as used in cmake. I think something like --qmake or --qmake-executable would be just fine (the leading QT_ in cmake is used for consistency with other Qt related variables; I guess it can be omitted in the argument name).

[probonopd]

How are macdeployqt and windeployqt handle this?

Would you like to send a Pull Request @mhoeher?

[mhoeher]

Hi @probonopd,

from my experience with both macdeployqt as well as windeployqt, they are a core part of each Qt distribution and as such always use their "sibling" qmake in the installation they are living in.

I have nothing ready yet to request pulling in, however, if you like I could look into it (given you can wait for some days, I mostly find time at weekends recently for coding stuff).

[probonopd]

Yes, no hurries, would be great if you could have a look.

[mhoeher]

Hi @probonopd,

I just tried to implement the option as I had it in mind ;-) CIs are running.

As a remark: It generally seems to work (I can deploy a locally build app with a custom Qt installed in my home with that new option). However, for some reason linuxdeployqt deploys the system Qt5DBus library instead of the one from my home directory. However, this does not seem to be related with the change, as the very same happens when adjusting $PATH instead. Is this a known issue?

[probonopd]

Hi @mhoeher thanks for your PR. I haven't been aware of the Qt5DBus issue so far and I have no hypothesis what causes it so far.

[mhoeher]

Having a night to sleep between the try and now, I think I have a possible explanation for the issue:

Actually, the correct DBus library (aka the one from the Qt installation in my home directory) gets deployed. What does not work is the following: The app I tested links again libqt5keychain, which is installed from the system repository. This library links against both the system libQt5Core.so and libQt5DBus.so. IIRC "mixing" Qt distributions is not officially supported. Especially in this case I assume that the system Qt and the one installed via the official installed use different compile/linker flags and even might be compiled against different system libraries. Bottom line: This does not seem to be an issue in linuxdeployqt but something the user has to take care of (by having copies of the libraries to deploy compiled and linked against the Qt distribution used by the main app).