On Jun 11, 2009, at 2:38 PM, Ryan Schmidt wrote:
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.
Except that there's no reason why one or the other implementation in the Portfile needs to map directly to one or the other UI
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.
Of course, that's significantly more complex (and repetitive) in the Portfile.
It's also more programatic (and less declarative).
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.
Platform variants are "special" (and not without their own problems because of their 'magic').
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.
It's also been something that we've recommended not using since the problems with it were discovered after upgrade was implemented.
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.
I don't see why that is necessarily the case.The maintainer can make the 'best' default choice (as has been done here) and the variant descriptions can say "Emulate foo instead of bar"
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.
... and in this specific case, that's probably an even better solution.
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.
Of course, this is what bin: and path: style dependencies were originally for ;-)
-- Daniel J. Luke +========================================================+ | *---------------- [email protected] ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
