[kde-freebsd] Should QtGui's cmake files add /usr/local/include?

[Raphael Kubo da Costa]

Adriaan de Groot <groot at kde.org> writes:

> In file included from
> /home/adridg/src/kwidgetsaddons/tests/kcolumnresizertestapp.cpp:23:
> In file included from /usr/local/include/qt5/QtGui/QtGui:32:
> In file included from /usr/local/include/qt5/QtGui/qopenglcontext.h:62:
> /usr/local/include/qt5/QtGui/qopengl.h:110:12: fatal error: 'GL/gl.h' file not
>       found
[...]
> So, given that you *may* need /usr/local/include in the build as well, and
> that parts of Qt5 assume that that path is present, shouldn't that directory
> be added to the search path somehow? Perhaps the thing to do is avoid #include
> <QtGui>, but that requires upstream KDE to cooperate.

And also:

> .. I should add that one could do this in a CMakeLists.txt:
>
> include_directories(${Qt5Gui_OPENGL_INCLUDE_DIRS})
>
> Except that Qt5GuiConfigExtras.cmake doesn't set that either (The list of
> include-directories to add is empty). That would make it easier / more stand-
> outtish to add that include directory to things that #include <QtGui>.

This is basically https://bugs.freebsd.org/195105, caused by my fix to
https://bugs.freebsd.org/194088, both of which are related to
https://bugreports.qt-project.org/browse/QTBUG-40825.

The quick and dirty solution to this problem is to set CPATH to
/usr/local/include and LIBRARY_PATH to /usr/local/lib when building
Qt5-based software (we do that automatically in Mk/Uses/qmake.mk, but
that obviously does not work if you are building your programs by hand.

I welcome input on how to better deal with this: just adding
/usr/local/{include,lib} back to the freebsd qmake mkspec causes Qt5
upgrades to fail. Perhaps doing something in the build process so that
Qt5GuiConfigExtras.cmake includes the proper GL paths may help at least
the CMake-based ports.