Qt4 as both framework and library

[Michael Dickens]

On Sep 19, 2012, at 12:02 PM, Craig Treleaven <ctreleaven at cogeco.ca>
wrote:
> Appreciate all the effort you have and continue to put into making Qt as painless as possible!

Thanks! And, that's the goal: as painless as possible.  qt4-mac is a BIG
compile, so I try hard to avoid requiring a recompile any more often
than necessary.  We've been disabling variants and moving them to "easy
to install" ports, with the eventual goal to get qt4-mac down to just
variants for +examples, +demos, +debug, and +universal.  That's still a
ways off, but hopefully it'll happen -- doing this reduces the compile
complexity of qt4-mac, while still allowing useful features via "easy to
install" ports that depend on qt4-mac.

> One aspect I'd like to ask about, however, is packaging.  At some point in the future (which never seems to get any closer!), I would like to try making an mdmg with Myth, which, of course, depends on Qt.  Will the dual library/framework for Qt cause a problem?

As far as I know, the dual-install won't cause any problems.  All of the
ports that I've installed that directly depend on Qt4 end up with
binaries (libraries and executables) that "otool -L" shows depend on the
framework, not the library link -- so, I guess the linkers we're using
are smart enough to follow symlinks and use the destination framework
file.  For this sort of packaging, chunks of Qt would be copied over (at
least the frameworks in use), and internal to the application a script
is executed when the application is started that sets the DYLD load path
to look inside the application first, then look to the system second. 
Hence, as the application starts up the DYLD should find all of the
frameworks correctly.

I hope this answers your question, as best I understand it and the
situation. - MLD