[kde-freebsd] Please review my (hopefully) final Qt 5.3.2 commits

[Max Brazhnikov]

On Sun, 19 Oct 2014 21:01:05 +0300 Raphael Kubo da Costa wrote:
> Hi everyone (particularly Max and Alberto),
> 
> I believe all the work for updating Qt5 to 5.3.2 is done. I've been
> committing smaller parts of the required changes for a while now, but
> left the big, disruptive changes for the end.
> 
> The pending diff was quite big to manually divide into separate commits
> for SVN, so I ended up doing them in git for now, and will commit them
> in the right order to area51 once someone else looks at and OK's them.
> 
> The commits are here:
> https://github.com/rakuco/freebsd-ports/commits/qt-5.3.2

Everything looks quite reasonable, so I'm fine with all changes.
 
> Specifically, I'm interested in feedback on 12b281c ("Call qmake from
> the root of the ${WRKSRC}") and 2787663 ("bsd.qt.mk: Set QMAKESPEC
> instead of QMAKEPATH"). Even after looking at several commits in area51
> (such as r8728, r8841 and r10019) it wasn't clear why we were doing so
> many weird things with qmake and qtbase's configuration script (like
> calling qmake directly in pre-configure and post-configure while passing
> -dont-process to the configure script). I believe the explanations to my
> changes make sense, but I'd really like you guys to see if I got
> everything right since you were doing the Qt5 work before.

I only updated it from 5.2.0-beta to 5.2.1 (according to the logs). I didn't
dive deep into the building system. r10019 was a temporal solutions, which
actually runs qmake from the root of ${WRKSRC} (otherwise ports fail to
build due to missing files which are generated by calling qmake),
but I didn't find time for proper fixing it.
 
> In addition to that, I don't think we need to change QMAKE_ARGS with the
> contents of QT_CONFIG and QT_DEFINES, but I didn't find a good
> explanation for why we were doing that in the first place (r8782), but
> at least the Poudriere builds of the qtbase ports without those worked
> fine.

I don't know what they are needed for. I'd like to see Alberto's comment
on this matter.

> Lastly, I'm fairly convinced 7492a2c ("Stop explicitly passing
> ${LOCALBASE} to the compiler") is the only way to fix ports/194088, but
> feedback is also welcome.

This may break 3rd-party software and ports which relay on this includes,
but I don't consider this as a drawback: passing additional flags when you
need them is much easier, than removing flags when they bring problems.

Max