Since CMake 2.8.6 its internal find_package command supports optional mode, which is similar to macro_optional_find_package. However, it uses CMAKE_DISABLE_FIND_PACKAGE_<PackageName> variable to disable find_package(). This is different from macro_optional_find_package, so it would be nice to have a helper function for this case in addition to current use_* functions.
Do you know of a package or have a sample CMakeLists.txt that can be used to test?
An example follows: project(cmake-fp-test) cmake_minimum_required(VERSION 2.8.6) include(FeatureSummary) find_package(KDE4) set_package_properties(KDE4 PROPERTIES DESCRIPTION "K Desktop" URL "http://kde.org/") feature_summary(WHAT ALL) The command `cmake -DCMAKE_DISABLE_FIND_PACKAGE_KDE4=True <src_dir>` does not check for KDE4 avaliability
That's pretty nifty. What do you think, cmake-utils_use_find_package
(In reply to comment #3) > What do you think, cmake-utils_use_find_package Oops. That should say: cmake-utils_use_find_package() { _use_me_now_inverted CMAKE_DISABLE_FIND_PACKAGE_ "$@" ; }
(In reply to comment #4) > cmake-utils_use_find_package() { _use_me_now_inverted > CMAKE_DISABLE_FIND_PACKAGE_ "$@" ; } the usage would look like: myconf+="$(use_find_package kde KDE4)" ? Seems like the name is most correct I can imagine. But it is quite long, however. KDE Frameworks want to migrate to this fucntionality (see their CMake Epic). Isn't it indeed too long for the (to bee) so frequently used function? Maybe just cmake-utils_use_package() would be enough?
We would usually be doing something like: local mycmakeargs=( $(cmake-utils_use_enable foo) $(cmake-utils_use_find_package bar BAZ) ) While the function name is a bit long, I don't think it's too long. That said, I don't really have an opinion either way - use_package sounds fine too. :) I will wait a little bit to see if anyone else cares to offer an opinion.
We need _use_ to indicate USE flag value dependency. (or.. do we?) While cmake-utils_use_find_package is not very consistent with cmake-utils_use_{with,enable}, it's because of CMAKE_DISABLE_FIND_PACKAGE_xxx not being consistent with WITH_xxx/ENABLE_xxx.. cmake-utils_use_find_package looks fine imho.
As a matter of fact, cmake-utils_use_package sounds fine as well - both are equally inconsistent though. Given the circumstances, let the shorter win?
Added to the overlay. http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=commit;h=7377cba6c5cff8076368acfc5d8cf79ac2fd0b00
Thanks, fixed in CVS. + 07 Feb 2013; Michael Palimaka <kensington@gentoo.org> cmake-utils.eclass: + Export src_prepare. Improve support for dev-util/ninja wrt bug #439608. Add + support for CMAKE_DISABLE_FIND_PACKAGE wrt bug #453746.