> On Dec 7, 2016, at 11:04 AM, Joshua Root <j...@macports.org> wrote:
> 
> On 2016-12-8 03:07 , Ryan Schmidt wrote:
>> 
>>> On Dec 7, 2016, at 4:20 AM, René J.V. Bertin <rjvber...@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.

Reply via email to