On Jun 11, 2009, at 08:37, Daniel J. Luke wrote:
On Jun 11, 2009, at 1:50 AM, Ryan Schmidt wrote:
I find it simpler to set things up like the above example instead
(this avoids an extra variant and avoids having to indicate
conflicting variants).
To me, it's the difference between whether the option, if it were
presented to the user in a GUI, were presented as a checkbox or as
a set of radio buttons.
Since they produce the same output, and MacPorts doesn't present
checkboxes or radio buttons to the user, I don't think that that's
really a valid distinction.
I think it is valid, since several MacPorts GUIs have already been
produced over the years, and Juan Germán is working on one for GSoC
2009.
Radio buttons and checkboxes are well-established and well-understood
metaphors and I see no compelling reason to ignore them and try to
invent something new for the user to need to understand.
The difference is that one method results in 2 variants that
conflict plus the 'magic' of default variants. Once you mix in the
registry not storing negative variants, I think you end up with
ugly user interaction if the user wants the non default one
(especially when he/she goes to upgrade it - unless that has been
fixed?)
Unconditionally using default_variants in a port is bad and will
cause the problem you describe. Conditionally using default_variants
only when none of the conflicting variants have been selected by the
user should work fine. I have been using it in ports for years.
Ideally, ports should be coded so that a user need never use a
negative variant (until that hypothetical future day when Registry
2.0 lets us remember negative variants, at which point we can revisit
this guideline).
Having required features in a default variant also breaks the
conceptual model of the no variant version of the port being the
normal/recommended/featureful version with variants being special
cases.
I suppose I don't necessarily have that conceptual model. I mean, we
already break that assumption with platform variants. And the
default_variants feature has been in MacPorts for longer than I've
been here, is documented, is part of the public port interface and is
in use by ports. Until default_variants and platform variants are
removed from MacPorts (and I have no reason to believe this will ever
happen), we will have some ports that install with a variant even
when you did not ask for one, and this need not cause the user any
discomfort.
More justification for this way of using variants:
Case 1: Mini vMac can emulate a number of old Macintosh computers.
For simplicity, the developer decided to offer no way to select this
or any other options at runtime; everything must be selected at
compile time. In the minivmac 2.x portfile, I implemented this by
having variants for each Macintosh model you can emulate:
$ 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
$
They are all marked as conflicting with one another, and if you don't
select one, +macplus is selected for you, because that is the
original and best-tested emulation and the one the developer
recommends. To me, this variant presentation makes it clear that the
user has a choice of five options, and which one will be selected by
default.
If the +macplus variant were omitted, it would be less clear, and the
user would have to consult perhaps the port's description to find out
what happens if he does not select any variant. And it would be more
difficult to represent clearly in a GUI.
Note that for the minivmac-devel 3.x portfile, in the interest of
having fewer choices, I have removed these variants, and now always
build all emulators, by running multiple make commands.
Case 2: PDFTK compiles using GCJ, which Xcode does not include.
Therefore PDFTK needs to depend on a GCC port. Currently you can
choose between using gcc41 or gcc42. The default, if the user has not
chosen otherwise, is to use the newest, gcc42, via the +with_gcc42
variant. (The "with_" variant naming is unfortunate and I wish it had
not been used, but that's another matter.) When variants are used to
select a compiler, having a variant for the default compiler also
serves a very useful function. If some day a new version of PDFTK is
released which can be compiled with a newer version of GCJ than that
in gcc42, then #15420 can be resolved and a gcc44 variant can be
added which will then be made the default. But a user who already had
a prior version of PDFTK installed with, say, the gcc42 variant
selected, will thus continue to use that compiler when upgrading the
port. If there had been no variant for the default compiler, the user
would be forced to install gcc44 at this point, which takes a
nontrivial amount of time on the best hardware and an absolute
eternity on older Macs.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
