[MacPorts] #14147: port lint should warn on illegal variant names

[Rainer Müller]

MacPorts wrote:
> #14147: port lint should warn on illegal variant names
> -------------------------------------+--------------------------------------
>  Reporter:  ryandesign at macports.org  |       Owner:  macports-tickets at lists.macosforge.org
>      Type:  enhancement              |      Status:  new                                  
>  Priority:  Normal                   |   Milestone:  MacPorts base enhancements           
> Component:  ports                    |     Version:  1.7.0                                
>  Keywords:                           |  
> -------------------------------------+--------------------------------------
>  `port lint` should warn when it encounters variants whose names are not
>  composed entirely of legal characters. I'm not sure if the list of legal
>  characters for variant names has ever been defined anywhere before, but
>  looking through all variant names of all ports right now, I see that they
>  are all composed of letters A-Z and a-z, numbers 0-9, underscore and
>  hyphen/dash, and the hyphen/dash is the only one of those that causes
>  problems. (A variant with a hyphen/dash in the name cannot be selected.)
>  So `port lint` should warn if a variant name does not match the regular
>  expression `^[A-Za-z0-9_]+$`
> 
>  Related: the guide should say something about valid variant names; see
>  #14141.

In ''proc variant'' itself are no checks at all, the first argument 
("provides") is taken as the variant name (see port1.0/portutil.tcl, 
proc variant {args}).

But in other places there are checks for validity.

port1.0/portutil.tcl, handle_default_variants:
  if {[regexp {([-+])([-A-Za-z0-9_]+)} $v whole val variant]} {

port/port.tcl, split_variants:
  set l [regexp -all -inline -- {([-+])([[:alpha:]_]+[\w\.]*)} $variants]


If there should be no hyphens/dashes in variant names, the regex in the 
ticket is correct and the one in handle_default_variants is wrong. I am 
unsure if I understand the regex in split_variants correctly... Maybe 
they should be unified to a single regex for variant names which can be 
used in multiple places.

Rainer