[MacPorts] #48024: charm-qt5 @1.8.0_20150312: cannot evaluate portfile

[MacPorts]

#48024: charm-qt5 @1.8.0_20150312: cannot evaluate portfile
------------------------+-------------------------
  Reporter:  larryv@…   |      Owner:  rjvbertin@…
      Type:  defect     |     Status:  new
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:
Resolution:             |   Keywords:  haspatch
      Port:  charm-qt5  |
------------------------+-------------------------

Comment (by rjvbertin@…):

 heads-up: it seems the build process is now churning through QtTools only.
 IIRC that's the component built just after QtBase, so it's not unlikely
 this is going to run for the rest of the day.

 I did run into an issue with the block below, but that was the only thing
 I had to and did fix (change) before launching the build. We'll have to
 see if QtWebengine builds too, there appears to be more "magic" applied to
 that component than I found necessary.

 {{{
     # see #44934 (and #35067 for the qt4-mac version)
     if { true } {
         set framework_list [split ${qt_frameworks_dir} '/']
         set qt_list        [split ${qt_dir} '/']

         while {[llength ${qt_list}] && [llength ${framework_list}]} {
             set var_qt        [lindex $qt_list        0]
             set var_framework [lindex $framework_list 0]

             if { ${var_qt} ne ${var_framework} } {
                 break
             }

             # remove first element from list
             set qt_list        [lreplace ${qt_list}        0 0]
             set framework_list [lreplace ${framework_list} 0 0]
         }
         set libreplace [string repeat ../ [llength ${qt_list}]][join
 ${framework_list} /]
         # RJVB: reinplace should be done in the post-patch
         post-patch {
             if { ${libreplace} ne "lib" } {
                 patchfiles-append patch-shared.diff
                 reinplace "s|__MACPORTS_FRAMWORK_DIR__|${libreplace}|g"
 ${worksrcpath}/qttools/src/macdeployqt/shared/shared.cpp
             }
         }
     }
 }}}

 the reinplace was being done unconditionally, even while doing `port info`
 or `port lint`. It's probably coincidence this worked with the author's
 setting for `qt_frameworks_dir`.

 About that block: I haven't tried to understand what the Tcl code does
 exactly. Compared to Michael's fix, it seems rather construed; in Qt4 the
 macdeployqt issue could be fixed with a very simple patch to the source
 code without any reinplacing, possibly because of his choice of setting
 for the location of the frameworks.
 I do wonder about the utility though. macdeployqt is for creating
 autonomous app bundles. Is that a supported use for MacPorts (I guess I
 don't have to enumerate here what MacPorts features and principles are
 borked by bundling of this kind)?

-- 
Ticket URL: <https://trac.macports.org/ticket/48024#comment:14>
MacPorts <https://www.macports.org/>
Ports system for OS X