declaring variants/subports in loops and loop variables

[Joshua Root]

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.

- Josh