On Tue, Jan 6, 2015 at 2:32 AM, René J.V. <[email protected]> wrote:
> On Tuesday January 06 2015 14:36:22 Ian Wadham wrote: > > >BTW Xcode, Apple's IDE, has quite a good facility for searching and > browsing > >Apple developers' documentation and is a pre-requisite for MacPorts (not > for > >the IDE, but for the system software that comes with Xcode). > > In fact, Xcode is the only way to peruse an offline copy of the API > documentation on OS X that I know of. > > >> If it's akin to a shared library on linux why aren't they used more > often? > > > >Dunno. But a Framework is more than just a shared library and does not > >actually have to include a library or any code… :-) > > 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? > > >> 3. How does one typically build Qt on this platform? When I do it here > with qt5 cloned from kde:qt5 using branch 5.4 and a separate qt5build > folder where I run ../qt5/configure -qpa cocoa and such the resulting > output doesn't show Cocoa as a QPA it is building. Also it doesn't seem to > build (nor does configure --help show any options to enable) QtScript to > build, which is required for some frameworks. > > Did you read Digia's build instructions for OS X? I'm guessing that they > set things up so that you need to use little to no build options... > I rebuilt overnight and have a somewhat usable Qt now, but it's missing Qt5DBus somehow, and I don't see any obvious configuration options for it. The Qt5 I installed from the digia installer has Qt5DBus, so it should be possible to build it on OS X... I'll dig a bit more today to figure out why it's not built. > > >BTW, there is already a port of qt5-mac 5.3.2 on MacPorts, but we cannot > install > >it concurrently with Qt 4. René is working on that problem. > > Sadly he cannot force things. I think my work on the qt4-mac side is done > and available as a draft for testing on trac.macports.org; I'm waiting > for feedback from people. That in turn might motivate the port maintainer > to make a move... > What's complicating matters is that qt4-mac and qt5-mac have different > maintainers who apparently didn't follow the exact same way of doing things > (if that's at all possible) and who both appear to have more important > things to do... > I see, ok, maybe we can put more weight on getting a workable solution there too :) BR, Jeremy > > R > _______________________________________________ > [email protected] > List Information: https://mail.kde.org/mailman/listinfo/kde-mac > KDE/Mac Information: http://community.kde.org/Mac >
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
