#47994: gnuplot +qt5: build failure ----------------------------+--------------------- Reporter: jinxiaoyong@… | Owner: mojca@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: gnuplot | ----------------------------+--------------------- Changes (by mojca@…): * cc: mojca@… (removed) * cc: mcalhoun@… (added) * owner: macports-tickets@… => mojca@… * version: 2.3.3 => * keywords: gnuplot qt => * port: gnuplot-5.0.0_0 => gnuplot Comment: The paths have been fixed in r137301, but the build fails: {{{ In file included from qtterminal/qt_term.cpp:51: In file included from /opt/local/libexec/qt5-mac/include/QtCore/QtCore:10: /opt/local/libexec/qt5-mac/include/QtCore/qvariantanimation.h:49:21: error: redefinition of 'QVariantAnimation' class Q_CORE_EXPORT QVariantAnimation : public QAbstractAnimation ^ /opt/local/include/QtCore/qvariantanimation.h:60:21: note: previous definition is here class Q_CORE_EXPORT QVariantAnimation : public QAbstractAnimation ^ In file included from qtterminal/qt_term.cpp:51: In file included from /opt/local/libexec/qt5-mac/include/QtCore/QtCore:10: /opt/local/libexec/qt5-mac/include/QtCore/qvariantanimation.h:51:5: error: static data member 'staticMetaObject' not allowed in anonymous struct Q_OBJECT ^ /opt/local/include/QtCore/qobjectdefs.h:160:30: note: expanded from macro 'Q_OBJECT' static const QMetaObject staticMetaObject; \ ^ }}} -- Ticket URL: <https://trac.macports.org/ticket/47994#comment:2> MacPorts <https://www.macports.org/> Ports system for OS X

#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 mojca@…): OK, so basically this seems to be a problem with existing `qt4-mac` installation (which is a problem you don't have because you likely don't have `qt4-mac` installed). -- Ticket URL: <https://trac.macports.org/ticket/47994#comment:4> MacPorts <https://www.macports.org/> Ports system for OS X

#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