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

Jake Thomas Petroules jake.petroules at petroules.com
Tue Jun 18 21:44:08 CEST 2013


I like this idea very much and think we should look into it further.

There is a long way we can go with integrating Qt into Apple platforms better at every level and this would be a great start.
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation ยท www.petroules.com
Email: jake.petroules at petroules.com

On Jun 18, 2013, at 3: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130618/25bed88f/attachment.html>


More information about the Development mailing list