[kde-freebsd] maintainer-feedback requested: [Bug 199297] devel/qmake5: package may leak WRKSRC references in qt_targspec and qt_hostspec, breaking Qt5 ports

[bugzilla-noreply at freebsd.org]

Alexey Dokuchaev <danfe at FreeBSD.org> has reassigned Bugzilla Automation
<bugzilla at FreeBSD.org>'s request for maintainer-feedback to kde at FreeBSD.org:
Bug 199297: devel/qmake5: package may leak WRKSRC references in qt_targspec and
qt_hostspec, breaking Qt5 ports
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199297



--- Description ---
I normally build my ports with WRKDIRPREFIX=/usr/obj (central scratch-space for
building world, kernel, and ports).  On machines with lots of RAM, I make
/usr/obj a symlink to /tmp.  It turns out that this combination leads to
producing silently broken qt5-qmake package, which in turn breaks Qt5 consumer
ports.

The problem typically exhibits itself like this, when you start building some
software that is based on Qt5:

> CMake Error at /usr/local/lib/cmake/Qt5Core/Qt5CoreConfig.cmake:15 (message):
>   The imported target "Qt5::Core" references the file
> 
>     
"/usr/local/lib/qt5//mkspecs//usr/obj/usr/ports/devel/qmake5/work/qtbase-openso
urce-src-5.4.1/mkspecs/freebsd-clang"

Looks like CMake-related bits of Qt5 had become tainted somehow.  Doing "grep
-R /usr/local/lib/cmake/Qt5Core" shows only one bad file:

>
/usr/local/lib/cmake/Qt5Core/Qt5CoreConfigExtrasMkspecDir.cmake:set(_qt5_coreli
b_extra_includes
"${_qt5Core_install_prefix}/lib/qt5//mkspecs//usr/obj/usr/ports/devel/qmake5/wo
rk/qtbase-opensource-src-5.4.1/mkspecs/freebsd-clang")

This file is generated (while building devel/qt5-core) port from
src/corelib/Qt5CoreConfigExtrasMkspecDir.cmake.in:

> !!IF isEmpty(CMAKE_HOST_DATA_DIR_IS_ABSOLUTE)
> set(_qt5_corelib_extra_includes
\"${_qt5Core_install_prefix}/$${CMAKE_HOST_DATA_DIR}/mkspecs/$${CMAKE_MKSPEC}\"
)
> !!ELSE
> set(_qt5_corelib_extra_includes
\"$${CMAKE_HOST_DATA_DIR}mkspecs/$${CMAKE_MKSPEC}\")
> !!ENDIF

CMAKE_MKSPEC is set to QMAKE_XSPEC during the build; in turn, QMAKE_XSPEC value
is provided by qmake; let's see what it yields:

> /usr/local/lib/qt5/bin/qmake -query QMAKE_XSPEC
>
/usr/obj/usr/ports/devel/qmake5/work/qtbase-opensource-src-5.4.1/mkspecs/freebs
d-clang

Running strings(1) over qmake binary indeed shows that bogus paths are embedded
in it:

> strings /usr/local/lib/qt5/bin/qmake | grep spec=
>
qt_targspec=/usr/obj/usr/ports/devel/qmake5/work/qtbase-opensource-src-5.4.1/mk
specs/freebsd-clang
>
qt_hostspec=/usr/obj/usr/ports/devel/qmake5/work/qtbase-opensource-src-5.4.1/mk
specs/freebsd-clang

Why does it happen?  Let's take a look at configure script:

> # the directory of this script is the "source tree"
> relpath=`dirname $0`
> relpath=`(cd "$relpath"; /bin/pwd)`
> ...
> shortxspec=`echo $XQMAKESPEC | sed "s,^${relpath}/mkspecs/,,"`
> shortspec=`echo $QMAKESPEC | sed "s,^${relpath}/mkspecs/,,"`
> ...
>    "qt_targspec=$shortxspec",
>    "qt_hostspec=$shortspec",

At this point it becomes fairly obvious.  Calling dirname(1) won't expand the
symlinked path (/usr/obj), but pwd(1) will!  So $relpath now starts with /tmp,
while $XQMAKESPEC and $QMAKESPEC are relative to /usr/obj; this confused sed(1)
and it cannot strip the prefix.

Quick and dirty fix is to patch devel/qmake5/Makefile like this:

> -QMAKESPEC=	  ${WRKSRC}/mkspecs/freebsd-${QMAKE_COMPILER}
> +QMAKESPEC=	  ${WRKSRC:tA}/mkspecs/freebsd-${QMAKE_COMPILER}

This trick won't work on systems with old make(1), e.g. FreeBSD 8.x.  The
problem, however, is not really about just qmake.  I suspect that there might
be more hidden bombs in our framework, not necessarily Qt5-related, that can
cause similar breakages.  I do not have a clean solution at hands for the
moment.

I'm not attaching any test cases or patches; I hope my analysis and description
are clear enough for our Qt/Mk maintainers, so they can work out the best
solution.