#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 feedback). The following mess-up is almost bound to lead to issues too: {{{ #file=qt5-1.0.tcl [...] # 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