[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