[KDE/Mac] Getting started on Mac OS X

[Ryan Schmidt]

> On Jan 6, 2015, at 6:28 AM, Jeremy Whiting wrote:
> 
>> Frameworks typically contain something that is indeed equivalent to a shared library, but as Ian said, they'll also contain header files (if required of course) and possibly other stuff. It is basically just a standalone prefix to some library (say, libfreetype built with configure --prefix=/Library/Frameworks/Freetype.framework/Versions/2) with the library binary renamed to the framework basename, some relocations, a bunch of symlinks for easy access, and most of all, compiler and linker adaptations so they know what to do with the .framework object.
>> I'm not sure what you mean with "used more often". If you mean outside of OS X, well, there could be any number of reasons, but the main ones could well be that 1) the principle is patented and 2) it's really not that useful/practical at the end of the day.
>> 
> Ok I see, so it's basically a place for a dependency of many applications (library) to contain all it's headers and library itself.
> 
> As for "used more often" I mean why don't VirtualBox and other applications that use Qt ship a Qt framework that they link to, but instead bundle Qt libraries inside their .app? Just for the convenience of being able to do VirtualBox.app -> Applications installations instead of a wizard type that puts the framework in place?

Frameworks are primarily useful for Apple itself: Apple can ship various frameworks as part of OS X and application developers can use them as they consume various OS X APIs. If Apple makes backward-incompatible changes to a framework and releases a new version of it in a new version of OS X, it can also include older version(s) of the framework in the Versions directory of the framework so that older compiled apps linked with the older versions of the framework still work. For example, on Yosemite, Tcl.framework and Tk.framework include both versions 8.4 and 8.5, and Python.framework includes both versions 2.6 and 2.7.

Frameworks are less useful for libraries provided by third-party developers. It would not be appropriate for third-party applications to install a copy of e.g. Qt.framework into /Library/Frameworks and link with it, because each application might install a different version of the framework, breaking other applications that were trying to use a different version. I would not trust an arbitrarily large number of teams of third-party developers not aware of one another to be careful enough to handle a shared multiple-version framework correctly. The only viable solution for applications that need to link with third-party libraries is for those applications to include copies of the desired versions of those libraries in their application bundle. It does not matter at all whether those libraries are packaged into frameworks or are just compiled as normal dynamic libraries.