How can variant B imply variant A?

Mojca Miklavec mojca.miklavec.lists at gmail.com
Wed Aug 22 07:50:51 PDT 2012


On Wed, Aug 22, 2012 at 4:34 PM, Bradley Giesbrecht wrote:
>
> On Aug 22, 2012, at 7:20 AM, Michael Dickens wrote:
>
>> Hmm … does (I think it's called) rev-update do its thing after installing from archive?  It's the post-install "Updating database of binaries" and "Scanning binaries for linking errors" check.  If it does, then it should catch the linking error between qt4-mac +framework and gnuplot, though I'm not sure what it can do if an older version of gnuplot was installed from archive that is not compatible with the current qt4-mac install.  The archival capabilities can only go so far in terms of variants.
>>
>> I have thought about qt4-mac's dual library / framework build, since it causes these sorts of issues.  I'm wondering if trying to install qt4-mac as dual framework / library would work: install as framework internally (to the Qt build), and then link from the frameworks into ${prefix}/include/Qt* and ${prefix}/lib/libQt*.  The former is already done, and seems to work well.  Doing the latter is a relatively simple extension of the former.  If both libraries and frameworks were installed, always, then dependent ports could choose which one to link to and would, after the change, always be backwards compatible with older versions.  Yes, this might make sense to look into.
>>
>> Thoughts on the above? - MLD

That means removing the +framework option altogether and making
frameworks by default? To me, having a nicely structured frameworks +
symlinks to enable "old-fashioned" ;) applications to work properly
sounds reasonable. (Then you can also patch pc files :)

> Would frameworks work as a subport;

They could, but ...

> letting qt4-mac dependent ports pick what they want to depend on?

... my guess is that any given port doesn't care at all whether it
depends on qt4-mac, qt4-mac-devel, qt4-mac +framework or qt4-mac-devel
+framework, subports or not. The only important part is that it has to
use the same version/variant out of the four I mentioned as the one it
was compiled for. At the moment the Portfile looks like

    variant qt description "Enable qt terminal" {
        depends_lib-append      port:qt4-mac
        configure.args-append   --enable-qt
    }

How should it look if I wanted to support either of the four
options/subports mentioned above? I guess it complicates matters. For
hardly any gain. Ports that have to depend on a different python
version might have a reason to do so (incompatible with a certain
python version). For Qt, + or - framework is just cosmetics.

Mojca


More information about the macports-dev mailing list