[MacPorts] #27558: qt4-mac @4.7.1 adding 'framework' variants

MacPorts noreply at macports.org
Mon Dec 6 19:08:44 PST 2010


#27558: qt4-mac @4.7.1 adding 'framework' variants
------------------------------------+---------------------------------------
 Reporter:  youngtaek.oh@…          |       Owner:  michaelld@…           
     Type:  enhancement             |      Status:  new                   
 Priority:  Normal                  |   Milestone:                        
Component:  ports                   |     Version:  1.9.2                 
 Keywords:                          |        Port:  qt4-mac               
------------------------------------+---------------------------------------

Comment(by michaelld@…):

 Let me comment on specifics of what you wrote:

 (1) The +debug issue happens no matter if installed as a framework or not:
 if qt4-mac wasn't installed as +debug and you want debug libraries, you'll
 need to reinstall with +debug.  Making 'debug' an option greatly reduces
 compile time, and many users don't care if debug libraries are installed.
 When both release and debug versions are installed, most Qt applications
 crash the first time they are executed but work after that -- it's a Qt
 issue, not an OSX one, to the best of my testing & knowledge.  Setting
 DYLD_IMAGE_SUFFIX can be made to work, but it's not very reliable in my
 testing (which, again, might not be thorough enough), and the user needs
 the OSX debug system libraries installed -- so, many ports intentionally
 provide a "+debug" variant to use that version of the library.  QMake and
 CMake both robustly support linking with the debug libraries.

 (2) Moving libraries to have release and debug (not in a framework) allows
 for explicit linking to either one; you cannot easily do that in a robust
 (generic) manner in any framework to the best of my efforts (or, maybe I
 didn't try hard enough :).  One can still use DYLD_IMAGE_SUFFIX to access
 the debug version if linked with the release version (with the same issues
 as in a non-framework).

 So, unless you (or anyone else) can come up with something better than
 "because that's the way, uh huh, uh huh, I like it, uh huh, uh huh", then
 I'm leaving it as is for now.

-- 
Ticket URL: <https://trac.macports.org/ticket/27558#comment:4>
MacPorts <http://www.macports.org/>
Ports system for Mac OS


More information about the macports-tickets mailing list