[cmake-developers] [CMake] CMake 2.8.3-rc1 ready for testing!

[Alexander Neundorf]

On Monday 27 September 2010, Brad King wrote:
> 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

Yes.

> from future CMake versions while working with older CMakes.

Not really.
In KDE 4.0 and 4.1 we had a FPHSA.cmake from maybe cmake 2.4.6 or something.
Once we required a newer version of cmake, I removed our copy.

We would now have the same problem, if I wouldn't have removed this copy and 
if we (KDE) would still have a copy of FPHSA.cmake from e.g. cmake 2.6.0.

This is what I do in general and what AFAIK is also recommended for others: if 
a cmake module does not exactly what you want, include a copy of it in your 
sources and tweak the copy.

This can be done in a compatible way.
But it will always fail when a new version of cmake comes with a new version 
of Foo.cmake which it uses itself, and relies on the new features.
If cmake then gets the older tweaked version from the project we have the 
problem.

...
> > 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.

hammer:~/src/CMake/CMake-git/Modules$ grep FindPackageHandleSt *cmake |wc -l
86

IMO this would justify that new variable.
(actually I wondered quite a few times since using cmake why such a  
CURRENT_LIST_FILE_DIR variable is missing, using GFC() always feels like 
using a clever trick instead of doing the straightforward thing).

Alex