[52043] trunk/dports/tex/texlive_base

[Daniel J. Luke]

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
+========================================================+
| *---------------- dluke at geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
|   Opinions expressed are mine and do not necessarily   |
|          reflect the opinions of my employer.          |
+========================================================+



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090611/e1a2866b/attachment.bin>