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

[BRM]

----- Original Message ----

> From: "Craig.Scott at csiro.au" <Craig.Scott at csiro.au>
> On 25/05/2011, at 10:39 PM, Charley Bay wrote:
> 
> > What about  out-of-the-box support for static library linking?  While not 
>perfect for  every application, large desktop applications like Maya could 
>simply  statically-link the required Qt version, and never suffer the 
>"anomalies" of  system Qt library upgrade.
> I have some sympathy for you with regard to  Maya (we also develop plugins for 
>Maya). Even if Maya statically linked its own  Qt libraries, that wouldn't 
>really help you. To be able to pass Qt objects  (QWidget, etc.) between your 
>plugin and Maya itself, you would need a shared Qt  between the two (see below 
>for why).
> 
> 
> > I've  built-and-statically-linked Qt, but IMHO it would be nice if the static 
>libs  were a first-class deployment option (e.g., automatically available when 
>Qt is  installed, I'm a commercial customer).
> We've found that rather than  statically linking to Qt, it is better for us to 
>ship our own Qt libraries with  our applications and to use launch scripts/apps 
>that modify environment  variables before launching the real binary. For 
>example, we put only launchers  in the bin/ directory and we put the real 
>binaries in lib/, and the launchers  add the lib/ directory to the PATH 
>(Windows), LD_LIBRARY_PATH (Linux) or  DYLD_LIBRARY_PATH (Mac - with mods for 
>frameworks too). Since the environment  variables are only augmented when the 
>launcher runs and the modifications only  apply to the process and not 
>system-wide, the changes made don't affect anything  else in the system other 
>than the specific binaries in your package that you  want to use them on. One 
>advantage of this is that you don't need to worry about  what Qt libraries are 
>installed on the system. Another is that if you want to  make your application 
>available on the system path, you can add your bin/  directory to the PATH and 
>not h
>  ave to modify the system LD_LIBRARY_PATH or  anything like that. You also 
>avoid the situation where your own Qt libraries  might interfere with the system 
>ones (and I've had to work around packages that  unfortunately do this when they 
>put their bin/directory on the PATH under  Windows but they also put their Qt 
>libraries in there). By using the launchers  approach, you can make your 
>executables available to the users system-wide, but  you don't have to pollute 
>the system's library paths or be affected by the  system's Qt libraries (if 
>present). We also make our launchers augment  QT_PLUGIN_PATH plus a few other 
>app-specific things, but you get the idea  (hopefully!). Note that this works 
>across all platforms, but it only works if  you can control the way apps are 
>launched. Thus, this won't work for Maya or  other situations where you are only 
>supplying libraries or plugins for other  packages.
> 

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.
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.

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

Ben