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.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
