[Interest] OS X Sandboxing and IPC (my experience so far)

[Till Oliver Knoll]

Am 24.05.12 14:16, schrieb morten.sorvig at nokia.com:
> 
> On May 19, 2012, at 4:59 PM, ext Till Oliver Knoll wrote:
>>
>> I prefer to install just what I need with my own *.pro/qmake script - it 
>> turns out that macdeployqt installs every possible framework, ...
> I've uploaded a patch that updates the macdeployqt plugin logic [1], perhaps this fixes the to-many plugins and frameworks issue?

It would be great if 'macdeployqt' would get some love :) I'd trade my
own deployment script anytime with that tool, as soon as a few quirks
would get ironed out (or I am "holding it wrong" maybe?).

Anyway, currently I get all possible Qt frameworks deployed with a
simple Qt Gui application (the one you create with Qt Creator with "New
-> Qt-Widget-Project -> ...", for instance):

drwxr-xr-x   4 tknoll  staff  136 29 Mai 20:40 QtCore.framework
drwxr-xr-x   4 tknoll  staff  136 29 Mai 20:40 QtDeclarative.framework
drwxr-xr-x   4 tknoll  staff  136 29 Mai 20:40 QtGui.framework
drwxr-xr-x   4 tknoll  staff  136 29 Mai 20:40 QtNetwork.framework
drwxr-xr-x   4 tknoll  staff  136 29 Mai 20:40 QtScript.framework
drwxr-xr-x   4 tknoll  staff  136 29 Mai 20:40 QtSql.framework
drwxr-xr-x   4 tknoll  staff  136 29 Mai 20:40 QtSvg.framework
drwxr-xr-x   4 tknoll  staff  136 29 Mai 20:40 QtXmlPatterns.framework


Even though the *.pro file only sais:

  QT += core gui

So I'd expect only the QtCore and QtGui frameworks to be deployed.

As a matter of fact the actual application binary ("QDeployMac") has no
dependencies on any other Qt framework:

otool -L QDeployMac
QDeployMac:
	@executable_path/../Frameworks/QtGui.framework/Versions/4/QtGui
(compatibility version 4.8.0, current version 4.8.1)
	@executable_path/../Frameworks/QtCore.framework/Versions/4/QtCore
(compatibility version 4.8.0, current version 4.8.1)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 7.9.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
830.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 125.2.11)


So there is only a direct dependency on QtGui and QtCore (when deploying
the application with only those frameworks, it perfectly runs on a
machine with no Qt installed at all).

> If you run macdeployqt with -verbose=2 you should see how the various frameworks are pulled in.

The first line reads: "Deploying Qt frameworks found inside: [bundle
path], followed by WHAT is copied (all the above frameworks, for
instance) - but not why.

> This sort of maintenance is unfortunately needed since the plugin deployment logic is implemented as a black-list (deploy all plugins with exceptions). 

And I guess since all frameworks are deployed, all possible plugins are
deployed as well, even the QML related ones.

It would be nice to be able to - somehow - control what plugins are to
be deployed. Or create different "sets" as an option (e.g. "Standard",
"Imaging", "Networking", "Codecs", ...), or more finegrained, have the
plugins named individually (or a combination thereof).



If I would end up with only a few plugins too much, I'd be already very
happy (I could always delete them again with a "post-processing"
installation steps - not nice, but perfectly acceptable).

Doing all these "install_name_tool" steps manually (in my own script) is
a pain and very errorprone.


> We might consider doing it differently for Qt 5 and use a white-list instead.

Another little improvement could be to make "macdeployqt" callable on a
previously "deployed" bundle.

Currently I get the message:

"Could not find any external Qt frameworks to deploy in "QDeployMac.app"
WARNING: Perhaps macdeployqt was already used on "QDeployMac.app" ?
WARNING: If so, you will need to rebuild "QDeployMac.app" before trying
again.
"

In my own script I check whether the source framework is newer than the
target framework, and if so, overwrite the target.

Like this I wouldn't need to delete the bundle, simply because I
recompile a single *.cpp file and link my binary again (off course the
"install_name_tool" steps would have to be re-applied onto my binary by
"macdeployqt").


Cheers, Oliver