2012/10/18 Michael Jackson <imikejack...@gmail.com>: > ... This is all done with symlinks and does work very well. If someone wants > to point me to the specific Apple document that says NOT to do this I will > happily change my code otherwise I'll keep going this route.
Most probably this: https://developer.apple.com/appstore/guidelines.html - Mac App Store rules, notably the way an application is supposed to be bundled and self-contained etc... Of course if you never plan to deploy there, that's no issue then ;) However there is a valid use case for dynamic linking (I'll leave the discussion "framework vs dynamic library" to away for sake of simplicity, I really want to focus on "static vs dynamic linking"): Sandboxing and Privilege Separation. Assume you want to implement an "application which also accesses the network": according to Apple it is good practise you split the networking part from the rest of the application (which can access the file system, for instance). You do this by implementing (at least) two binaries inside the same Bundle, with different Entitlements (the "networking binary" cannot access the filesystem, the main binary cannot access the network etc.). So you can at least share QtCore, and if the networking binary should also render some GUI elements on its own (I'd consider this bad practise, but for the sake of argument...) you could even share QtGui - instead of linking both libraries statically into both binaries :) Now when linking statically and after removing "dead" code in both binaries, in theory you could /still/ end up with less code than in the dynamic case - to be honest I don't know. But as soon as you start to use a "reasonable amount" of the Qt API in both binaries, I dare to say your application bundle becomes smaller in the dynamic linking case :) Cheers, Oliver _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
