[Interest] Deploying Qt to MacOs still...errr, sucks?

[René J.V. Bertin]

On Tuesday February 10 2015 10:22:57 Daniel França wrote:

> Not the smoothest deployment process, but at least it's working. (except
> that it's full of aliasing even with antialising: true, but it's another
> story)

IMHO Qt for Mac really should be able to use the fontconfig font engine like Qt for Windows can. When Freetype is installed with the Infinality patches it actually gives better text rendering than CoreText (and who knows, maybe Qt will also gain better support for less standard typefaces like medium or semi-bold, instead of replacing them with regular or bold).
If you want to file a request for that I'll +1 it.

> 
> Em Tue Feb 10 2015 at 4:32:58 AM, Thiago Macieira <thiago.macieira at intel.com>
> escreveu:
> 

> > That must be the same MacPorts leak issue.

Yep. The "funny" part of that issue is that Qt's own binaries are generated with a HUGE "rpath" stored in them, which makes it possible to install the distribution just about anywhere and still have enough margin to edit those paths with a simple binary file editor (you can shorten static strings by putting a nullbyte somewhere, but you cannot of course lengthen them).
For some reason the packager decided not to use install_name_tool for that, and also forgot to take care of the MacPorts dependencies.
I don't know if install_name_tool is always present on user machines or if it requires the developer tools (which are required anyway for using what the Qt installer installs...). If one can rely on it, it seems a good idea to use that tool to adapt the Qt libraries to the user's chosen install location and handle any remaining MacPorts dependencies at the same time.
That's all the more true if the tool allows something like `install_name_tool -change /opt/local/lib /usr/lib`, i.e. a path change rather than a path+file change.

R.