[Qt5-feedback] Qt major versions (was: C++ api to use for UI in addition to QML)

[Craig.Scott at csiro.au]

On 27/05/2011, at 5:33 PM, BRM wrote:

There is also the various linker options to add the 'lib' directory in your
program path to the binary's search.
We install Qt to /usr/local/TrollTech/Qt-<version> on our systems and link
specifically against that path. No editing LD_LIBRARY_PATH on Linux.

That's okay if you don't want your package to be relocatable. If you want a relocatable package, using RPATH support (which I think is what you are talking about here) breaks. But if you don't care about relocatable packages and you know where your Qt libs will be installed (ie a very controlled set of deployment machines), then RPATH does save you from having to modify LD_LIBRARY_PATH. There's still the issue of QT_PLUGIN_PATH, but if you are not providing your own designer plugins, etc., then that shouldn't affect you. The situation on Mac is effectively the same as on Linux too.


On Windows, you can do the same thing though we just drop the DLLs in parallel
to the executable as you don't typically put the application path in the PATH
anymore, just drop a shortcut on the desktop - and in that respect the shortcut
could have an alternate working path too to achieve the same effect.

Yep, for a fully self-contained app, this should work fine. Personally, I'm in favour of giving users the choice of putting your bin directory on their PATH if they want to, which means keeping your libs separate, but that's a view formed by having to provide packages that some people want/need to be able to invoke from a command line (eg things that could be part of software build systems).


All I'm saying is, there are multiple ways to tackle the issue without having to
revert to static/convenience libraries.

Agreed, and I think the alternatives you mention are useful for the right scenarios.

--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia