passing variants to dependencies; pre-activate check

[David Strubbe]

Would something like this be a good idea to prevent multiple definition?
This could potentially be an issue with other nested portgroups too.

Index: dports/_resources/port1.0/group/active_variants-1.1.tcl
===================================================================
--- dports/_resources/port1.0/group/active_variants-1.1.tcl     (revision
141271)
+++ dports/_resources/port1.0/group/active_variants-1.1.tcl     (working
copy)
@@ -87,6 +87,12 @@
 #     dependencies, e.g., require_active_variants path:foo/bar:standardport
 #     variant

+default active_variants_included {}
+
+# only include this PortGroup once
+if {${active_variants_included} == ""} {
+    set active_variants_included "yes"
+
 proc active_variants {depspec required {forbidden {}}} {
        # get the port which will provide $depspec; this allows us to
support e.g.,
        # path-style dependencies. This comes from port1.0/portutil.tcl and
should
@@ -278,3 +284,5 @@
 pre-activate {
         _check_require_active_variants activate
 }
+
+}


On Tue, Oct 13, 2015 at 10:35 PM, Joshua Root <jmr at macports.org> wrote:

> On 2015-10-14 13:04 , David Strubbe wrote:
> >     > - Why is pre-activate code executed twice?
> >
> >     It isn't, two pre-activate procedures have been registered and they
> are
> >     each executed once.
> >
> >
> > Well, I only put one block of code in active variants, as below. Why
> > does it end up in two different pre-activate procedures?
> >
> > active_variants-1.1.tcl:
> >>
> >> +pre-activate {
> >> +    ui_warn "checking active variants"
> >> +    _check_require_active_variants archivefetch
> >> +}
>
> Looking at the portfile, it uses the compilers portgroup as well as
> active_variants. Looking at compilers, it uses active_variants itself.
> So active_variants is included twice.
>
> - Josh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20151013/6f1fe389/attachment.html>