Qt CMake Finding Issues

[Michael Dickens]

Hi Chris - Using various -DFOO=BAR defines usually work (since they pre-set cache values which are then used when doing a FIND_*), but in this case, for some reason, it does not.  I've defined:

     -DQT_QT_INCLUDE_DIR=${qt_includes_dir} \
     -DQT_LIBRARY_DIR=${qt_libs_dir} \
     -DQT_QMAKE_EXECUTABLE=${qt_qmake_cmd}

and a few others, but the FindQt4.cmake file resets the cached value via a FIND_LIBRARY or FIND_PATH function.  The one that -does- seem to work is for the QMAKE executable, which is good because that means so long as the last -D above is set, and we fix the rest of this module to just key off of the values provided by this specific QMake, then only one of the MacPorts' installs of Qt will be found, and found reliably too.  In this way, we can specify the one in ${prefix}/bin, or ${prefix}/libexec/qt*, or whatever we want.  To me, this seems like the easiest to implement solution -- which is important because I don't think we want to get caught up in elaborate changes that will just get broken down the road.  Simple, but functional, is best. - MLD

On Nov 18, 2010, at 7:44 AM, Chris Scharver wrote:
> I don't think the cmake modules are tailored for systems that might contain two different versions of Qt. Ports could specify the correct version when configuring with -D QT_INSTALL_PREFIX. Because MacPorts has both X11 and Aqua versions, ports need to declare which windowing system should be used, directly affecting where to search for Qt.
>
> I'll have to check the original module when I'm back at my Mac, but using cmake -D is the most explicit way to declare that a port using cmake looks for things in the right places.