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

[MacPorts]

#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@…):

 In my "poll" from a while back, nobody cared whether Qt was installed as
 frameworks or as "normal" libraries -- they just want the port and those
 that depend on it to work correctly (and, I did lots of checking to make
 sure this was the case).  So, I really don't think anyone is going to
 complain about moving back to a framework install if that's the end result
 of this ticket -- again, so long as dependent ports work correctly.

 From the developer's point of view of the ports that depend on Qt4, almost
 all use PKGCONFIG, QMake, or CMake to determine *FLAGS and such -- so
 those ports would work correctly after rebuilding / reinstalling to use
 the framework Qt install.  There are a few ports that would need to be
 worked over to find / use the framework install, since they use a static
 configure script that expects one way or the other; there aren't many of
 these luckily.

 Really, the biggest issue is a convenience factor for me:  I need to
 manually check the Qt4 install to see if it is +debug or not; the easiest
 way to do this right now is to look for
 "${prefix}/lib/libQtCore_debug.dylib" (and then assume the rest of the
 libraries follow).  Moving to a framework install I'd look for
 "${prefix}/Library/Frameworks/QtCore/QtCore_debug" I think -- so, really
 not a big issue so long as I know what to be looking for.

 If I know that the Qt4 install is a framework, then I know where to look
 for libraries and headers; if I know it's a normal install then I also
 know where to look for libraries and headers.  If I don't know what type
 of install it is, I have to to some work to find those libraries and
 headers.  For headers, I can create a soft link from
 ${prefix}/include/QtFOO into the FOO Framework & that takes care of that
 issue.  But, I cannot do the same for libraries without creating the
 debug/release problem we're discussing.  Hence, if any changes are made
 it'll be a move to just a framework install w/o the option for regular --
 I'm trying to keep patches and extra coding to a minimum.

 Ideally, MacPorts would be able keep track of not just the +universal
 variant (as well as the install arch type(s)) but also +debug and any
 other variants one might think of & do this checking automatically.  For
 example, if qt4-mac were not installed as +debug but did provide a +debug
 variant, and I then tried to install py26-pyqt4 +debug, then 'port' would
 error out saying that the +debug variant dependency could not be met w/o
 forcing (e.g., via the "-f" flag) the reinstall of any dependent port that
 accepts +debug -- much as it does for universal and arch right now.  This
 would also hold for any other variant (e.g., +quartz, +x11, or whatever).
 Right now, port doesn't do this, so we have to work around this sort of
 checking manually.  Which then brings us back full circle to this issue:
 if we know where files are located, then this checking is simple.  If not,
 then the checking is more complex.  The same holds for some dependent
 ports (knowing where to find Qt4 makes our patches to the release code
 simpler).

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