This solves a lots of warnings, e.g. in the FindModulesExecuteAll test. If the
installed version on the system is rather old this may even lead to bugs, e.g.
https://bugs.gentoo.org/show_bug.cgi?id=436540
...if the library file does not exist inside the .framework then do
not allow a library variable to be set to the path to the framework.
Force set it to NOTFOUND instead.
Remove old search paths that aren't needed.
Keep using PATHS instead of HINTS because a Windows machine may have
a different Qt in its PATH and putting QTDIR and the registry entry
ahead of PATH could cause apps to fail when run.
Ancient versions of CMake required else(), endif(), and similar block
termination commands to have arguments matching the command starting the
block. This is no longer the preferred style.
Run the following shell code:
for c in else endif endforeach endfunction endmacro endwhile; do
echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/'
done >convert.sed &&
git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' |
egrep -z -v '^(Utilities/cm|Source/kwsys/)' |
egrep -z -v 'Tests/CMakeTests/While-Endwhile-' |
xargs -0 sed -i -f convert.sed &&
rm convert.sed
If on APPLE, the phonon backend plugin is set to phonon_qt7. If on WIN32, the phonon backend plugin is set to phonon_ds9. I did not add any for generic UNIXes as they could have a whole host of things. A more comprehensive script would actually attempt to detect which phonon plugins were installed. However, this is a simple fix for now that will work for most people.
7a1027a When checking find_package() components, special case qtmain.
4c1c358 FindQt4: Include builtin FindPackageHandleStandardArgs directly
43cb9b8 Change to use fphsa to check required variables and version.
If a Qt installation is in CMAKE_PREFIX_PATH and a
QT_QMAKE_EXECUTABLE points to a qmake for a different Qt installation,
prefer finding libs in the latter Qt installation.
After discussing with Brad and Clinton:
-the namespace for the imported targets is now "Qt4::", tested with Makefiles, Visual Studio and XCode projects
-the imported targets are always created
-if QT_USE_IMPORTED_TARGETS is set to TRUE (it defaults to FALSE), the QT_QTFOO_LIBRARY variables are set to point to these imported
targets, otherwise the old behaviour is used.
-on OSX if Qt has been found as framework, disable QT_USE_IMPORTED_TARGETS, since cmake doesn't handle the framework directory as location of the library correctly
Alex
-set the type of the IMPORTED libraries to UNKNOWN, this way also on Windows
only the "LOCATION" property has to be set
-the if() around the SET(QT_${basename}_FOUND 1) was useless (always true)
-the mapping of the configuration types DEBUG and PROFILE did not belong here
Alex
This commit syncs FindQt4.cmake again with KDEs version.
Now for every Qt library an imported target with the name
Qt4ImportedTarget__<LIBNAME> is created.
This way we can now finally handle the release and debug versions of the Qt
libraries correctly.
Also, if a Qt-using project A installs a file with exported targets, these
targets now depend on the imported Qt targets, e.g.
Qt4ImportedTarget__QtCore. The location of QtCore is then resolved at
buildtime of project B, which uses the exported targets from project A.
Before this patch the full path to the QtCore on the original build machine
of project A was stored, so this had to match the directory layout on the
build machine for project B.
Alex
Now the case that both the release- and the debug-version of a library is
handled first, because otherwise we always ran into this branch, since the
debug-only and the release-only branch also set both variables.
Alex
before this patch -F<framework> dir had to be added manually in some way
when using Qt4 installed as framework and when using FindQt4.cmake directly,
i.e. without UseQt4.cmake. With this patch the framework dir is
automatically added to QT_INCLUDE_DIR when Qt is installed as a framework.
Ok by Clinton, tested already in KDE by Mike Arthur.
Alex
Qt4Macros.cmake: all the "public" macros of FindQt4.cmake
Qt4ConfigDependentSettings.cmake: the code for detecting the
Qt-configuration dependent additional libraries, e.g. when linking statically.
There should be no functional changes in this patch.
The patch reduces the length of FindQt4.cmake from 1700 lines to around 1000
lines, which is still long enough, but this should make the file a easier to
handle (and it is similar to what we do in KDE with FindKDE4Internal.cmake
and KDE4Macros.cmake)
Ok by Clinton.
Alex
This should not change the result (since both should be in the same
directory), but seems a bit more logical and is also in sync with what is done in the KDE version.
Alex
-the mark_as_advanced() calls for the variables coming from qmake are now in
the corresponding section, and not in the section where the include dirs are
foudn
Alex
-remove the parentheses in the if() conditions, they don't change the
result, and without them these lines are identical to the ones in
FindQt4.cmake from KDE
-mention which qmake was used for finding Qt
Alex
This adds copyright/license notification blocks CMake's find-modules.
Many of the modules had no notices at all. Some had notices referring
to the BSD license already. This commit normalizes existing notices and
adds missing notices.
Clinton Stimpson
Rolf Eike Beer
David Cole
Brad King
Stephen Kelly
Kitware Robot
Kurtis Nusbaum
David Faure
Mike McQuaid
Markus Rathgeb
Todd Gamblin
Alexander Neundorf