gnuplot +qt5: build failure

[jxy (Xiao-Yong)]

The new private dir installed qt5-mac breaks building of gnuplot-5.0.0_0 +qt5. The build stopped at

:info:build uic -o ui_QtGnuplotSettings.h qtterminal/QtGnuplotSettings.ui
:info:build make[4]: uic: No such file or directory
:info:build make[4]: *** [ui_QtGnuplotSettings.h] Error 1

But the configure was wrong as not finding the correct qt path.

CXXFLAGS='-pipe -Os -F/opt/local/Library/Frameworks -I/opt/local/Library/Frameworks/QtCore.framework/Versions/5/Headers -I/opt/local/Library/Frameworks/QtGui.framework/Versions/5/Headers -I/opt/local/Library/Frameworks/QtNetwork.framework
/Versions/5/Headers -I/opt/local/Library/Frameworks/QtSvg.framework/Versions/5/Headers -I/opt/local/Library/Frameworks/QtWidgets.framework/Versions/5/Headers -arch x86_64 -stdlib=libc++'

[jxy (Xiao-Yong)]

Refer to #44193 for the changes in qt5-mac.

[mojca (Mojca Miklavec)]

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; \
                             ^

[jxy (Xiao-Yong)]

The patch r137301 works for me. The files under /opt/local/include/QtCore/ are not part of qt5-mac. Probably it conflicts with another QT installation on your system?

[mojca (Mojca Miklavec)]

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).

[mkae (Marko Käning)]

Cc Me!

[RJVB (René Bertin)]

Yes, even with a proper implementation of a co-installable Qt5 port (like the ones I have been testing and making available for months now, via trac tickets and my personal port repository) you cannot have the current Qt4 port installed and active while building Qt5 applications. For that you'd need my co-installable qt4-mac port.

Not that this seems to be a Qt5 issue, but as a side-note: I contacted mcalhoun several times during the period I worked on making the Qt5 port co-installable with Qt4 and he (or she) never even bothered to reply, not even when in the end I asked if someone else should take over maintainership. It'll be interesting to see how quickly issues that arise with the new version of the port are going to be addressed ...

[u.g.the.sky@…]

Cc Me!

[RJVB (René Bertin)]

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.

[mojca (Mojca Miklavec)]

I blindly assume that this issue was fixed after switching to a different layout of qt4-mac (r140960). If there are still problems, please reopen this ticket or open a new one.