2014-12-20 1:37 GMT+03:00 Vadim Zhukov <[email protected]>:
> 1. When Qt4 came in, there were almost no qmake4 users.
> Now there are many:
>
> cad/fritzing/Makefile: ${LOCALBASE}/bin/qmake4 -o Makefile
> phoenix.pro
> cad/openscad/Makefile: ${SETENV} ${QMAKE_ENV} qmake4 ${QMAKE_FLAGS}
> openscad.pro
> devel/beediff/Makefile: cd ${WRKSRC} && ${LOCALBASE}/bin/qmake4 beediff.pro
> devel/qt-creator/Makefile: cd ${WRKBUILD} && QTDIR=${WRKDIR}/bin qmake4
> ${WRKSRC}/qtcreator.pro #CONFIG+=debug
> devel/qt-creator/Makefile: qmake4 ${QTCDH_SRC_DIR}/gdbmacros.pro; \
> devel/qt4-eventsview/Makefile: cd ${WRKDIST} && env -i ${CONFIGURE_ENV}
> qmake4
> devel/qt4-qtsolutions-singleinstance/Makefile: cd ${WRKSRC} &&
> ${LOCALBASE}/bin/qmake4
> editors/focuswriter/Makefile: cd ${WRKSRC} && ${SETENV} ${MAKE_ENV}
> ${CONFIGURE_ENV} ${LOCALBASE}/bin/qmake4
> editors/qscintilla/Makefile: cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV}
> ${LOCALBASE}/bin/qmake4 \
> editors/teaqt/Makefile: cd ${WRKSRC} && qmake4
> editors/texmaker/Makefile: qmake4 -spec
> ${MODQT_LIBDIR}/mkspecs/openbsd-g++ \
> editors/tiled/Makefile: qmake4 -makefile tiled.pro -config release
> games/jag/Makefile: cd ${WRKSRC} && ${LOCALBASE}/bin/qmake4 Game.pro
> games/pokerth/Makefile: env -i ${CONFIGURE_ENV} qmake4 ${MAKE_FLAGS} \
> geo/gpsbabel/Makefile: cd ${WRKSRC}/gui && ${SETENV} ${CONFIGURE_ENV} qmake4
> \
> geo/merkaartor/Makefile: cd ${WRKSRC} && env ${CONFIGURE_ENV} qmake4
> PROJ=1 NODEBUG=1 RELEASE=1 \
> graphics/opencsg/Makefile: cd ${WRKSRC} && qmake4 src.pro
> multimedia/mlt/Makefile: cd ${WRKSRC}/src/tests; ${SETENV}
> ${ALL_TEST_ENV} qmake4 tests.pro
> net/qsynergy/Makefile: @cd ${WRKSRC} && ${LOCALBASE}/bin/qmake4
> net/retroshare/Makefile: cd ${WRKSRC} && ${LOCALBASE}/bin/qmake4
> RetroShare.pro
> productivity/entomologist/Makefile: ${LOCALBASE}/bin/qmake4
> ${CONFIGURE_ARGS}
> productivity/fet/Makefile: cd ${WRKSRC} && ${LOCALBASE}/bin/qmake4
> fet.pro
> productivity/vym/Makefile: ${LOCALBASE}/bin/qmake4
> DOCDIR="${PREFIX}/share/doc/vym" vym.pro
> security/fwbuilder/Makefile: --with-qmake=qmake4 \
> security/kqoauth/Makefile: cd ${WRKDIST} && ${LOCALBASE}/bin/qmake4 \
> security/qca-gnupg/Makefile:QMAKE =
> ${LOCALBASE}/bin/qmake4
> security/qoauth/Makefile: cd ${WRKDIST} && ${LOCALBASE}/bin/qmake4 \
> security/yubikey-personalization-gui/Makefile: cd ${WRKSRC};
> CXXFLAGS="${CXXFLAGS}" qmake4
> sysutils/bacula/Makefile: QMAKE=${LOCALBASE}/bin/qmake4
> www/arora/Makefile: @cd ${WRKSRC} && ${LOCALBASE}/bin/qmake4 -r
> www/minitube/Makefile: ${LOCALBASE}/bin/qmake4 PREFIX=${PREFIX}
> x11/lumina/Makefile: cd ${WRKSRC} && ${LOCALBASE}/bin/qmake4
> x11/py-qt4/Makefile: --qmake="${LOCALBASE}/bin/qmake4" \
> x11/qrfcview/Makefile: ${LOCALBASE}/bin/qmake4 rfcview.pro
> x11/qwt/files/Makefile.examples: qmake4 $$I.pro && env
> LOCALBASE=${LOCALBASE} gmake; \
> x11/qwt/Makefile: @cd ${WRKSRC} && qmake4 -d -d -d
>
> 2. Now that Qt5 is coming in, and given that some ports already (and
> many more will) support both Qt4 and Qt5, it may result in
> maintaince burden, to tweak each such port in the way:
>
> .if ${FLAVOR:Mqt5}
> ...
> .else
> ...
> .endif
>
>
> I think everything above is job for port modules instead. So I
> propose to create x11/qt/qt.port.mk, that will call the right qmake.
> I left out all other logic duplicated between qt4.port.mk and
> qt5.port.mk, to allow print/poppler build (Qt5 support is on its
> way there already).
>
> The only real change is that MODQT*_WANTLIB becomes a trick itself:
> you can set up both MODQT4_WANLTIB and MODQT5_WANTLIB in a port,
> and use MODQT_WANTLIB in actual WANTLIB. This way you'll get the
> WANTLIB you want depending on Qt version you're using.
>
> The obvious downside is that we'll have a lot of "-qt5" FLAVORed
> ports...
>
> An alternative approach could be switching all Qt4 users to Qt5,
> or, at least, making sure that Qt4 won't mix in otherwise Qt5-ready
> software. Please remember that Qt4 will come out-of-support after
> 2015 ends, so we have to move quickly, and get everything clean
> at the 5.8 release lock.
>
> I don't insist on getting this in right now, but asking for ideas
> and comments for now. Thank you for your time.
I forgot to talk about this part:
> -MODQT4_CONFIGURE_ARGS = --with-qt-includes=${MODQT4_INCDIR} \
> - --with-qt-libraries=${MODQT4_LIBDIR}
> -MODQT_CONFIGURE_ARGS ?= ${MODQT4_CONFIGURE_ARGS}
There are no MODQT4_CONFIGURE_ARGS users in ports tree, so this
variable likely could go away. Any objections?
--
WBR,
Vadim Zhukov