[MacPorts] #47994: gnuplot +qt5: build failure

MacPorts noreply at macports.org
Tue Jun 9 04:51:04 PDT 2015

#47994: gnuplot +qt5: build failure
  Reporter:  jinxiaoyong@…  |      Owner:  mojca@…
      Type:  defect         |     Status:  new
  Priority:  Normal         |  Milestone:
 Component:  ports          |    Version:
Resolution:                 |   Keywords:
      Port:  gnuplot        |

Comment (by rjvbertin@…):

 So it seems mcalhoun did reuse my version of the qt5 portgroup definition
 (with many thanks again for [not] mentioning this nor soliciting any final
 The following mess-up is almost bound to lead to issues too:

 # standard install directory
 global qt_dir
 set qt_dir               ${prefix}/libexec/qt5-mac
 global qt_archdata_dir
 set qt_archdata_dir  ${qt_dir}
 set qt_dir              ${prefix}/libexec/${qt_name}

 So after setting a new variable `qt_archdata_dir` (which I fail to see the
 exact meaning of) to ${prefix}/libexec/qt5-mac, `qt_dir` and a whole slew
 of variables are redefined to use `${prefix}/libexec/qt5` as in my
 implementation. I think (but haven't bothered to check) that this must
 lead to having both directories under ${prefix}/libexec being used, which
 is completely unnecessary. Even if it doesn't, there is still the global
 `qt_archdata_dir` variable that's "exported" and that is likely to lead to
 confusion at some point down the road.

 Again, I don't see the point of that variable.  Qt itself (through the
 qtchooser utility) distinguishes between a QTTOOLDIR (where tools like
 qmake are expected) and a QTLIBSDIR (where the binary libraries are
 expected). The former is the most important and corresponds to
 `qt_bins_dir`, the latter evidently corresponds to `qt_libs_dir`. See my
 submission for port:qtchooser. There's simply no need for an additional
 "archdata" concept.

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

More information about the macports-tickets mailing list