variants vs separate ports

[Bradley Giesbrecht]

On May 24, 2010, at 8:59 AM, Ryan Schmidt wrote:

> On May 24, 2010, at 10:29, Bradley Giesbrecht wrote:
>
>> I am working on a port where I must chose only one of five backend  
>> systems.
>>
>> The port is a plugin for dovecot called antispam.
>> The five backends are:
>> crm114-exec
>> dspam-exec
>> mailtrain
>> signature-log
>> spool2dir
>>
>> I was going to create five separate ports and conflict each port  
>> with the others.
>>
>> Optionally I could create one port with five variants and conflict  
>> the variants with each other. If I use variants there must be one  
>> and only one of the five backends chosen. I know I can conflict  
>> variants but I do not know how to force a variant.
>>
>> From a naming and maintenance standpoint I like one port with five  
>> variants vs five ports.
>>
>> dovecot-antispam
>>
>> vs
>>
>> dovecot-antispam-crm114
>> dovecot-antispam-dspam
>> dovecot-antispam-mailtrain
>> dovecot-antispam-signature
>> dovecot-antispam-spool2dir
>
> Conflicting variants is easy. Check out for example the  
> GraphicsMagick port's quality variants (q8, q16, q32).

Right, conflicting is easy. I looked for variant_isset in port sources  
and came up with this.
Would this be a reasonable way to ensure that a variant is set?
Keep in mind that ONE and ONLY ONE variant MUST be set.

pre-fetch {
     if {![array size variations]} {
         variant_set {mailtrain}
     }
}

Port appears to handle misspelled or nonexistent variations so [array  
size variations] seems to be zero if the user did not pass in valid  
variations for this port. I mention this incase the user is installing  
more then one package or if this port ever became a dependency and  
variations for other ports are on the command line.

// Brad