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