declaring variants/subports in loops and loop variables

[Ryan Schmidt]

> On Dec 7, 2016, at 11:04 AM, Joshua Root <jmr at macports.org> wrote:
> 
> On 2016-12-8 03:07 , Ryan Schmidt wrote:
>> 
>>> On Dec 7, 2016, at 4:20 AM, René J.V. Bertin <rjvbertin at gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> See https://trac.macports.org/ticket/53022#comment:2
>>> 
>>> I'm still waiting for the final verdict from the ticket reporter, but it seems that issue was one of those cases where I shouldn't have used a loop variable in the declaration scope of a variant (nor subport):
>>> 
>>> {{{
>>> set pythonversions {3.4 3.5}
>>> foreach pdv ${pythonversions} {
>>>   set pv [join [lrange [split ${pdv} .] 0 1] ""]
>>>   # snip
>>>   variant python${pv} description "Add bindings for Python ${pdv}" {
>>>       depends_libs-append port:python${pv}
>>>       # snip
>>>   }
>>> }
>>> }}}
>>> 
>>> Why is it that this makes both the +python34 and +python35 variants depend on the last value of ${pv}, and thus on port:python35? Are those declaration scopes somehow evaluated outside of the loop? That hypothesis is supported by the error that's raised when I unset pdv and pv immediately after the loop.
> 
> This is almost exactly the same situation as:
> 
> foreach foo {bar baz} {
> 	proc p_$foo {} {
> 		puts $foo
> 	}
> }
> p_bar
> p_baz
> 
> Try it in tclsh. (Variants are slightly different only in that they automagically bring all global variables into scope. Thus you get pv with its current value instead of a "no such variable" error.)
> 
>>> If so, is there a cleaner and not much more complex way to do loop-based variant/subport declaration such that at least the loop variables are undefined outside of the loop? Unsetting the variables works but isn't very elegant and too easy to forget.
>>> 
>>> R.
>> 
>> The boost port shows a typical example of using "eval" and "subst" to ensure the variable values are substituted immediately.
> 
> That sounds overly complicated (there should be almost no reason to use eval, ever.) Quotes instead of braces would allow variable substitution in the variant body.

I agree, it sounds overly complicated to me too, but it is at least a block of code that has been tested by someone and added to many ports and seems to work.