[MacPorts] #72163: eigen3 @3.4.0_1+blas+gcc5+universal: can't read "universal_archs_to_use": no such variable

[MacPorts]

#72163: eigen3 @3.4.0_1+blas+gcc5+universal: can't read "universal_archs_to_use":
no such variable
-------------------------+----------------------
  Reporter:  ar-an-ribe  |      Owner:  eborisch
      Type:  defect      |     Status:  assigned
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.10.5
Resolution:              |   Keywords:
      Port:  eigen3      |
-------------------------+----------------------

Comment (by ryandesign):

 Replying to [comment:3 ar-an-ribe]:
 > Replying to [comment:2 eborisch]:
 > > Not quite sure what to make of this. The portfile
 [https://github.com/macports/macports-
 ports/blob/2454f8fd911451bdc77e805b2716cdbef88bd477/math/eigen3/Portfile#L115
 explicitly checks] to see if ''universal_archs_to_use'' exists:
 > > {{{#!tcl
 > > pre-destroot {
 > >     set build_suffix {}
 > >     if {![info exists universal_archs_to_use]} {
 > >         lappend build_suffix ""
 > >     } else {
 > >         set dash "-"
 > >         foreach arch ${universal_archs_to_use} {
 > >             lappend build_suffix ${dash}${arch}
 > >         }
 > >     }
 > >     …
 > > }
 > > }}}
 >
 > Is this `pre-destroot` section executed before the configuration phase?
 (I’m not familiar with such MacPorts internals.)

 No, the `pre-destroot` blocks happen before the destroot phase. We have
 not gotten to the destroot phase—we're failing in the configure phase—so
 what this `pre-destroot` block does is irrelevant to this problem.

 Replying to [comment:4 barracuda156]:
 > The error may be related to the muniversal PG, perhaps.

 It is, to the extent that `universal_archs_to_use` is a variable defined
 by and used by the muniversal portgroup and other portgroups that need to
 behave differently when the muniversal portgroup is in use.

 It's weird for a port to check if it exists. It exists if the muniversal
 portgroup is included and it isn't if it isn't and a portfile author
 should know whether or not they have included a portgroup. The eigen3 port
 includes the portgroup conditionally, only when the blas variant is
 enabled, which is in turn weird.

 Code in variants isn't executed until after all the rest of the portfile
 code is executed, so when the blas variant is enabled the muniversal
 portgroup isn't included until after all the other portfile code,
 including code in the other portgroups that are included unconditionally
 at the top, has run. That's weird and portgroup authors haven't
 necessarily anticipated that portfile authors will use a portgroup in such
 a weird way.

 The error in the log comes from the fourth `pre-configure` block. There
 are no `pre-configure` blocks in the portfile, so these four `pre-
 configure` blocks must be in portgroups.

 {{{
 :debug:configure Executing proc-pre-org.macports.configure-configure-0
 :debug:configure Active variants check for source-type install considers
 depends_fetch depends_extract depends_lib depends_build depends_run:
 lbzip2 libgcc libgcc6 cmake pkgconfig gcc5
 }}}

 This first one is evidently from the active_variants-1.1 portgroup. The
 eigen3 port doesn't include it, but it does include the compilers-1.0
 portgroup which includes it.

 {{{
 :debug:configure Executing proc-pre-org.macports.configure-configure-1
 :debug:configure compilers.enforce_c list:
 :debug:configure compilers.enforce_fortran list:
 :debug:configure compilers.enforce_some_fortran list:
 }}}

 This second one comes from the compilers-1.0 portgroup.

 {{{
 :debug:configure Executing proc-pre-org.macports.configure-configure-2
 :debug:configure CPPFLAGS="-I/opt/local/include" inserted into CFLAGS="-Os
 -DNDEBUG -I/opt/local/include" CXXFLAGS="-Os -DNDEBUG
 -I/opt/local/include"
 }}}

 This third one comes from the cmake-1.1 portgroup.

 {{{
 :debug:configure Executing proc-pre-org.macports.configure-configure-3
 :error:configure Failed to configure eigen3: can't read
 "universal_archs_to_use": no such variable
 }}}

 This fourth one also comes from the cmake-1.1 portgroup and is the only
 place in that portgroup where it references the `universal_archs_to_use`
 variable.

 The muniversal portgroup sets up `universal_archs_to_use` in `proc
 universal_setup`. The portgroup never calls this proc. As a comment in the
 portgroup says, this replaces the proc of the same name in
 src/port1.0/portutil.tcl in MacPorts base. It's weird for a portgroup to
 replace parts of MacPorts base, but the portgroup does need to replace the
 functionality of the built-in universal variant, and this may have been
 the only way. `universal_setup` is called from `mportopen` in
 src/macports1.0/macports.tcl where the code reads:

 {{{#!tcl
     # add the default universal variant if appropriate, and set up flags
 that
     # are conditional on whether universal is set
     $workername eval [list universal_setup]

     # evaluate the variants
     if {[$workername eval [list eval_variants variations]] != 0} {
         mportclose $mport
         error "Error evaluating variants"
     }
 }}}

 So, it calls `universal_setup` and then it runs the code in the variants.
 Therefore including the portgroup in a variant is too late. The solution
 is to include the portgroup outside of a variant, e.g. at the top of the
 portfile like other ports do.

 If it needs to be included conditionally only when the blas variant is
 selected, that can be done:

 {{{#!tcl
 PortSystem          1.0
 PortGroup           compiler_blacklist_versions 1.0
 PortGroup           compilers 1.0
 PortGroup           cmake 1.1
 PortGroup           gitlab 1.0
 if {[variant_isset blas]} {
     PortGroup       muniversal 1.0
 }
 }}}

 But it would be preferable to include it either unconditionally or not at
 all. Portfiles often need to be written slightly differently depending on
 whether or not they use the muniversal portgroup. There's no need for the
 portfile author to put themselves through the additional pain of trying to
 design a portfile that can work whether or not the muniversal portgroup is
 included.

 I am left wondering how the conditional inclusion of the muniversal
 portgroup ever got added to the portfile. I can't see how it ever could
 have worked.

-- 
Ticket URL: <https://trac.macports.org/ticket/72163#comment:6>
MacPorts <https://www.macports.org/>
Ports system for macOS