On Dec 10, 2007, at 6:50 PM, Ryan Schmidt wrote:
On Dec 10, 2007, at 11:42, Weissmann Markus wrote:
On 10.12.2007, at 18:27, Ryan Schmidt wrote:
On Dec 10, 2007, at 08:43, Weissmann Markus wrote:
On 10.12.2007, at 15:23, Ryan Schmidt wrote:
On Dec 10, 2007, at 08:16, Weissmann Markus wrote:
Hmmm... wouldn't it be much cleaner and easier to only have one
variant "quartz" as "quartz" and "x11" are mutually exclusive
anyway?
Since there is a choice to be made for x11 support or quartz
support, I think it makes sense to list both of these as variants.
The port should (and now does) ensure that exactly one of these is
selected at all times.
well, I prefer to not making this a philosophical problem:
With one variant, you get two different installations, with two
variants, you get four.
That's certainly one way to use variants. That's the "checkbox" way.
In this case (gtk2), two of the four variants are "errors" and are
then fixed (with the defaults variant) or with a user warning. I
think it would be better to eliminate the problem altogether then
trying to fix it's effects.
I prefer to think of this as the "radio button" way. It's perfectly
acceptable to mark variants as conflicting with one another. That's
why the "conflicts" keyword exists. If I were writing a GUI to
install ports, I'd make it so variants were represented as
checkboxes, except when the "conflicts" keyword is encountered,
which turns those variants into radio buttons.
See also my minivmac portfile, which has 5 variants for selecting
which ancient Mac model you want it to emulate. Exactly one variant
must be selected. All the variants conflict with one another, and
one of them is the default:
$ port variants minivmac
minivmac has the variants:
mac128k: Emulate a Macintosh with 128K RAM and 2 drives
mac512k: Emulate a Macintosh 512K with 512K RAM and 2 drives
mac512ke: Emulate a Macintosh 512Ke with 512K RAM and 6 drives
macplus: Emulate a Macintosh Plus with 4 MB RAM and 6 drives
(default)
macse: Emulate a Macintosh SE with 4 MB RAM and 6 drives
$
Excellent example! Most often variants are used because of
shortcomings of software: You have to decide at build-time because the
software doesn't let you decide at run-time (or via config-file, etc.).
This is all an optimization problem where we have different goals,
like: max. functionality, min. space, min. compile-time, min. download
volume, etc., etc.
We have to decide which ONE of these is our primary goal. And so far
the consent has been to get max. functionality.
Example: minivmac makes you decide at compile-time which mac you want
to emulate.
Solution min. compile time: Variant for each mode.
Solution max. functionality: Compile all of them and install them side
by side (I'm sure this is possible)
With each variant a port has, the max. functionality value suffers:
The min. compile time solution of minivmac only offers 20% of the
functionality of the max. functionality version (for each variant).
Also the reproducibility suffers with each variant: Assume you got a
bug report for A failing which requires library B. If B has no
variants, you can reproduce the error on your machine (hopefully). If
B has two variants, you may have to test three times till you
reproduce it. And if B requires C which has another two variants you
get 9 possible installations to look into. And it is getting worse
exponentially with the dependency tree depth.
Therefore variants are for experienced users only and people who just
want stuff to work shouldn't have to select a single variant.
The default installation should provide the maximum reasonable*)
functionality. Try to avoid variants like the plague. If the software
forces you to make a choice, let the default choice be the most
reasonable one. If you have to force the user to make a choice, you're
most probably doing something wrong: Either install both choices (e.g.
minivmac - see above) or split the ports (e.g. openssl and openssl97).
Don't think of variants as cool knobs to fiddle around but as poor
workarounds for shortcomings of the software.
Of course variants can be useful if you cannot fix the software or for
features with minimal benefit which are extremely expensive (e.g.
support for gtk1, gtk2, motif, wxWidgets, Cocoa, QT AND SDL), for
switches that turn on experimental stuff, etc.
Regards,
-Markus
*) This means that if your port supports a functionality that only
three people on this planet might use and this feature conflicts with
a common one, you should move the uncommon one to a variant. E.g. if
the graphics front end supports gtk2 and motif, well, forget about
motif or put it into a variant for the huge crowd who loves motif.
--
Dipl. Inf. (FH) Markus W. Weissmann
http://www.macports.org/
http://www.mweissmann.de/
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
