Providing FindFoo.cmake for a kde module "foo"

[Andreas Pakulat]

On 08.07.07 21:55:17, Ralf Habacker wrote:
> Andreas Pakulat schrieb:
> > On 08.07.07 21:26:42, Ralf Habacker wrote:
> >> In the meantime I found a simpler way by appending all pathes from KDEDIRS (+ 
> >> 'share/apps/cmake/module') added to the CMAKE_MODULE_PATH  in 
> >> FindKDE4Internal.cmake. As an alternative the path list generated by 
> >> 'kde4-config --path data'  could be added.  This makes it able to use cmake 
> >> modules without any additional effort from *all* KDE install locations.
> >>     
> >
> > That sounds like a really good solution, except that currently KDEDIRS
> > is not needed to be set during compilation, only during runtime. 
> >   
> Then the usage of the 'kde4-config --path data' alternative will be 
> better. kde4-config is available when compiling kde package based on 
> kdelibs. FindKDE4.cmake uses kde4-config also so set the 
> CMAKE_MODULE_DIR to be able to find KDE4Internals.cmake

Sorry, I forgot something earlier on: People might have no permission to
write to the kdelibs-install-dir, which is one of the main reasons each
module can be installed into its own path. 

For example I currently have KDE3 installed via Debian packages, but I
build kdevelop3 from svn and install into $HOME. I can't install
kdevelop3 into /usr because that can and will screw up the packaging
tools - they expect that everything in /usr (/usr/local exempted of
course) is "owned" by them.

So using kde4-config --path data as destination for
FindKDevPlatform.cmake is not an option and neither is installing
KDevPlatformConfig.cmake into <kdelibs>/lib/kdevplatform.

Anyway, as I already said it is possible to use -DCMAKE_MODULE_PATH to
point cmake to a ;-separated list of additional .cmake-search-paths.

Andreas

-- 
You will be surprised by a loud noise.