[cmake-developers] [CMake] CMake 2.8.3-rc1 ready for testing!
Brad King
brad.king at kitware.com
Mon Sep 27 16:38:51 EDT 2010
On 09/25/2010 02:35 PM, Alexander Neundorf wrote:
> FIND_PACKAGE_HANDLE_STANDARD_ARGS(Ruby REQUIRED_VARS ${_RUBY_REQUIRED_VARS}
> VERSION_VAR RUBY_VERSION )
[snip]
> breakage, because KDE's version doesn't recognize the REQUIRED_VARS keyword.
At least it breaks instead of pretending to do what the caller asks ;)
> But cmake >= 2.8.3 and KDE 4.5.0/4.5.1 will be incompatible.
Ugh. This is KDE's "fault" for trying to mix-and-match modules
from future CMake versions while working with older CMakes.
On Saturday 25 September 2010, Eric Noulard wrote:
> I think we may need some sort of version handling
[snip]
> include(FindPackageHandleStandardArgs <x.y>)
FindPackageHandleStandardArgs is really a cmake-language library.
If we really want to support copies outside of CMake then we should
treat it as such:
# Load the macro right out of FPHSAConfig.cmake
find_package(FPHSA 2.8.3 NO_MODULE QUIET)
unset(FPHSA_DIR CACHE)
This will always fall back to the version provided with the running
CMake (which is always an exact-match version).
> The other option would be to make sure that
> INCLUDE(FindPackageHandleStandardArgs)
> when used in cmake's own module would always load
> FindPackageHandleStandardArgs.cmake from cmake, i.e. code like:
>
> GET_FILENAME_COMPONENT(_currentDir "${CMAKE_CURRENT_LIST_FILE}" PATH)
> INCLUDE("${_currentDir}/FindPackageHandleStandardArgs.cmake")
I think this is the simplest option. The module will work when
copied into KDE without needing a new CMake that supports a
new include() option or variable.
> Another option would be to add a new automatic cmake variable
> CMAKE_CURRENT_LIST_FILE_DIR, so we could simply do
IMO the variable is convenient but unnecessary. The GFC() call
makes it very clear what directory is used.
-Brad
More information about the cmake-developers
mailing list