declaring variants/subports in loops and loop variables

Ryan Schmidt ryandesign at macports.org
Wed Dec 7 16:07:31 CET 2016


> 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.
> 
> 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.



More information about the macports-dev mailing list