[Development] Why custom installer on Mac, why not using @rpath?

Raul Metsma raul at innovaatik.ee
Tue Jun 18 22:28:22 CEST 2013

I was also wondering why not distribute plugins in framework bundle.
It is easier to deploy frameworks with final application bundle and not have to mess with plugin paths.

Raul Metsma

On Jun 18, 2013, at 10:31 PM, Adam Strzelecki <ono at java.pl> wrote:

>> That might work for when QtCore is bundled with the executable, but it doesn't 
>> if QtCore is still installed system-wide and the executable (your application) 
>> is somewhere else completely. How will it find the plugins?
> I am perfectly aware than on some platforms it isn't possible to get path for the executable, requires messing with /proc or it may not even exists. That's why I all stuff below applies to OSX, and maybe can be brought to Windows.
> As a full-time Mac developer I may be biased towards way of OSX, but I think there's something wrong conceptually with Qt Mac frameworks architecture.
> Basically Qt Mac SDK looks like a mixture of contradictory OSX and UNIX concepts, where UNIX libraries use compile time "prefix" (/usr /usr/local /opt /sw), Mac frameworks never expect their location to be some particular path.
> So if libqcocoa.dylib is QtWidgets.framework plugin which is a Mac framework, it may be better idea to keep it as QtWidgets.framework/Version/5/PlugIns/Cocoa.bundle/Contents/MacOS/Cocoa. IMHO Some.app/Contents/PlugIns is reserved for application plugins not for their frameworks.
> This also applies to Qt built-in translations that should be in framework Resources etc. etc.
> So all frameworks know where to look for their plugins translations, etc. etc. because they're carried with them.
> Finally Qt SDK would be just a bunch of frameworks you can (selectively) link to, move around, copy to your app bundle, w/o any extra path tweaking. SDK could be just dmg package of:
> Qt5.1.sdk:
>  Samples/
>  Frameworks/
>  QT Creator.app
> If one don't need some features in the app they can be stripped away from particular framework, i.e. removing Headers/, particular translations in Resources/, particular widget backends in QtWidgets PlugIns/.
> What would be even more cool is to put the "moc", "qmake" tools into QtCore.framework/Versions/5/Support (symlinked to QtCore.framework/Support).
> Altogether this would make Qt SDK 100% OSX friendly. No need for installers, just add QtCore.framework/Versions/5/Support if you want use command line tools or symlink them to /usr/local/bin
> Some examples taken from my box:
> $ ls -l `which ruby`
> lrwxr-xr-x  1 root  wheel  76 26 lip  2012 /usr/bin/ruby -> ../../System/Library/Frameworks/Ruby.framework/Versions/Current/usr/bin/ruby
> $ ls -l `which java`
> lrwxr-xr-x  1 root  wheel  74 17 kwi 18:17 /usr/bin/java -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java
> Regards,
> -- 
> Adam Strzelecki | nanoant.com | twitter.com/nanoant
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

More information about the Development mailing list