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

[Alexander Neundorf]

On Sunday 26 September 2010, Alexander Neundorf wrote:
> 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.

First version of a patch is attached.

Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmake_current_list_file_dir.patch
Type: text/x-diff
Size: 2930 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20100926/d1552f13/attachment-0002.patch>