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. Chris -- Sent from my iPod On Nov 17, 2010, at 9:47 PM, Michael Dickens <[email protected]> wrote: > A number of ports are having issues either (1) finding qt4-mac's installed Qt > at all; and/or (2) finding a user-installed version of Qt instead (either > fully or partly; generally from the pre-compiled PKG from Nokia). I finally > broke down and downloaded the PKG version and installed it and did some > testing. Turns out that the issue is primarily broken CMake internal > functions FIND_LIBRARY and FIND_PATH (or, maybe, that the documentation on > them is incorrect). > > Turns out that the fix -for MacPorts' purposes only- is very simple: Because > Qt4 is installed into ${prefix} and subdirectories, we can restrict the > search space to just the info provided by "qmake -query QT_INSTALL_PREFIX" > and if that doesn't work then Qt wasn't found. I'm certainly -not- going to > mess around with the FIND_* functions internal to QMake, but I hope there is > a bug report open since they are definitely broken (at least w/r.t. the > ordering found in < > http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_library >). > See, e.g., the "FIND_LIBRARY" function call at about > ${prefix}/share/cmake-2.8/Modules/FindQt4.cmake:604, and then read through > the supposed searching order from the URL. > > The simple (obvious? non-robust?) solution is to add to any FIND_LIBRARY or > FIND_PATH call in the FindQt4.cmake file "NO_DEFAULT_PATH" if it is not > already there, or replace the other NO_* options with this one. > NO_DEFAULT_PATH restricts the search to just whatever paths or hints are > provided to the function. For MacPorts' usage, restricting is just fine > since what we really want is for the script to find the version installed by > MacPorts, and only that version, and to error out if not finding that version. > > Problem: FindQt4.cmake is installed by both 'cmake' and 'kdelibs4' -- as are > a host of other .cmake scripts. It looks like those provided by KDE are > older than those from CMake (which would make sense), so I'm inclined to > create a patch for the cmake version of FindQt4.cmake & then rev bump cmake > for it to take effect. I'd also be inclined to delete those installed by > KDE, just in case -- not all of the .cmake files, but just duplicates. > > Thoughts? - MLD > _______________________________________________ > macports-dev mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
