How can variant B imply variant A?

[Michael Dickens]

On Aug 22, 2012, at 10:34 AM, Bradley Giesbrecht <pixilla at macports.org>
wrote:
> Would frameworks work as a subport; letting qt4-mac dependent ports pick what they want to depend on?

I was thinking of what Majca wrote: just remove the +framework variant
entirely, and install qt4-mac as both framework and symlinked libraries
and includes.  The includes are already symlinked; adding libraries I
think won't be too difficult since I already pick the libraries based on
a dynamic listing of "${prefix}/Library/Frameworks/Qt*.framework". Just
need to set the version, which I think it's safe to assume can be that
provided in the Portfile (and, thus, not have to do anything like "otool
-L .. | grep .. | awk .." for each frameworks' library).  Anyway, this
would be a first cut, and I think it would solve a number of issues that
folks have had with Qt (and, one that I'm having right now with CMake
not recognizing the new frameworks location of qt4-mac; sigh).  I do not
envision +framework being a subport; not sure why I'd even want that
variant -- I mean, how many other ports have +framework as a variant? 
Not many, if any, I'd guess (no, I haven't checked).

Most ports use some combination of QMAke, CMake, GNU Autotools, and/or
pkg-config to determine the location of headers and libraries.  qt4-mac
installs files correctly for each of these.  The one outstanding right
now is CMake, which I'm hacking on right now to get "FindQt4.cmake" to
do the right thing with qt4-mac installed as libraries or frameworks. 
Moving to combined library / framework would solve this issue, since
CMake would just check for the library version and that would work
correctly.

- MLD