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 _______________________________________________ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd See also http://freebsd.kde.org/ for latest information