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

[Alexander Neundorf]

On Sunday 26 September 2010, Alexander Neundorf wrote:
> On Saturday 25 September 2010, Eric Noulard wrote:
> > 2010/9/25 Alexander Neundorf <neundorf at kde.org>:
> > [..]
> >
> > > 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")
> > >
> > >
> > > Should all
> > > INCLUDE(FindPackageHandleStandardArgs)
> > > in all find-modules from cmake be changed to this ?
> >
> > I don't think it's a good idea.
> > People may purposely want to override CMake provided module
> > in order to implement specific behavior and/or to patch locally.
>
> This is what we do in KDE, and I think it would be good for us.
>
> Using
> include(FPHSA CURRENT_DIR)
> in the files in cmake would mean that the find-modules in cmake also get
> the FPHSA they expect to get, and if we would use that in KDE too, we would
> be sure we would get our modified version.

Another option would be to add a new automatic cmake variable 
CMAKE_CURRENT_LIST_FILE_DIR, so we could simply do

INCLUDE(${CMAKE_CURRENT_LIST_FILE_DIR}/FindPackageHandleStandardArgs.cmake)

Wouldn't require any changes to include(), and can be used also for other 
things.

Alex