How can variant B imply variant A?
Mojca Miklavec
mojca.miklavec.lists at gmail.com
Wed Aug 22 00:23:33 PDT 2012
On Tue, Aug 21, 2012 at 9:46 PM, Jeremy Lavergne wrote:
>> Independent of all that, my two questions still stand:
>> - Is it possible to enable a variant if I'm already too late for
>
> How are you too late for this? I don't see how you can be too late.
If I use
variant x_qt requires qt4-mac ... {
...
}
this works fine.
If I use
variant x_wxt ... {
if {<something>} {
# then this is already too late to make a dependency on "wxWidgets"
} else {
# or dependency on "wxWidgets-devel" here
}
}
>> "variant ... requires ..."?
>> - Is it possible to use "if port X is installed" inside Y's Portfile?
>
> This is just a bad idea: your package will install differently based on what's available, and not even consistently (e.g. archives). Use subports with the appropriate dependencies.
In the idea I was brainstorming above, archives wouldn't be a problem
(other variants would take care of that), but it's true that the port
would install differently depending on whether one or the other
package is currently installed/activated. If it's more desirable that
the user is very explicit, it's no problem. One can require from the
user to be more explicit and specify one of two variants explicitly,
even though he is only able to install one of them based on what
wxWidgets he currently has. Clemens Lang nicely summarized my opinion
as well:
> Why is that a problem? In this case, the maintainer wants to
> specifically support both wxWidgets and wxWidgets-devel. The end-user
> either already made his choice on that (and chances are he'd select the
> same variants on this port), or he doesn't care, in which case the port
> can specify a sane default.
However I just noticed a "serious" problem in my current setup,
probably related to what you mentioned above.
I recently installed "qt4-mac +framework" and I just pulled an old
gnuplot out of archive (sudo port activate gnuplot @...) which now
crashes with
dyld: Library not loaded: /opt/local/lib/libQtNetwork.4.dylib
Referenced from: /opt/local/bin/gnuplot
Reason: image not found
Trace/BPT trap: 5
The same file is now in
'/opt/local/Library/Frameworks/QtNetwork.framework/QtNetwork'.
(I would not necessarily attempt to fix this though. Hardly any sane
person would try to mess with multiple installations/variants of Qt
and there was no other bug report related to that so far. I only
imagine it being a problem if a port depending on Qt is fetched from
buildbot and the user decided to install "qt4-mac +framework" variant
earlier. I'm not excluding the possibility that my setup is messed up
though, and that it's only broken on my machine.)
Mojca
More information about the macports-dev
mailing list