[kde-freebsd] Merging qt5-uitools->qt5/designer and qt5-qmldevtools->qt5-qml for Qt 5.3?

[Max Brazhnikov]

On Mon, 13 Oct 2014 00:26:28 +0300 Raphael Kubo da Costa wrote:
> I have finally reached a point in the Qt 5.3.2 porting process where all
> ports build correctly, and looking at the work as a whole I'd like to
> propose merging devel/qt5-uitools into devel/qt5-designer and
> devel/qt5-qmldevtools into lang/qt5-qml.
> 
> The main reason behind this is that Qt 5.3 and the upcoming 5.4 have
> introduced some changes to the build system and the mkspecs and we
> cannot just call qmake from a subdirectory like we did in many ports. I
> am now calling qmake from the top-level ${WRKDIR} and patching .pro
> files to exclude certain SUBDIRs as necessary.
> 
> For qt5-uitools and qt5-designer, it means adding a couple of patches to
> each port to build or not build the uitools subdirectory.
> 
> For qt5-qmldevtools, it means the "no_module_headers" sed call in the
> Makefile does not work anymore, qt5-qml is needed as a build-time
> dependency and the headers (which actually belong to qt5-qml and are
> also installed by it into a different location) cannot be installed
> anymore.
> 
> It's not entirely clear to me why these ports were split in the first
> place; from area51 r8887, I can only assume it's to avoid adding a lot
> of dependencies to the linguist ports (bug 190929 comes to mind).

Not to the linguist, but virtually to any Qt based port. libQtUiTools is
a very common dependency, and since we don't have qt4 port for it,
almost everything depends on heavy qt4-designer port (read qtwebkit).
The same situation with the linguist and lupdate/lrelease: if you need to
build l10n for simple Qt 4 port you have to install tons of stuff.

Alberto saved us from these problem for Qt 5 ports. Until the maintenance
cost are high I'd like to keep the UiTools and Designer separate.

> If
> that is indeed the case, we already have qt5-linguist and
> qt5-linguisttools with the latter having the translation tools used by
> most Qt-based ports. We could then make the actual qt5-linguist port
> depend on qt5-designer without many complains (I hope). As for
> qt5-qmldevtools, since the port now depends on qt5-qml to build and the
> header files it used to install are now shipped only by qt5-qml, I see
> little purpose in keeping it around.

I agree about merging qml ports, I don't see strong reason for keeping them
split.