[CMake] 3rd party cmake files

[Alexander Neundorf]

Hi,

> Von: Alexander Neundorf <a.neundorf-work at gmx.net>
> 
> > Von: Brad King <brad.king at kitware.com>
> > 
> > Jan Woetzel wrote:
...
> > > Extending cmake would be much easier and more "open"
> > > with an easy way to extend teh search path for FIND_PACKAGE.
> > 
> > What we really need is a way to make FIND_PACKAGE find the 
> > QtDBUSConfig.cmake file and set QtDBUS_DIR more robustly.  Then you 
> > would not need any FindQtDBUS.cmake file at all.  It looks like this was
> > overlooked in the recent FIND_* changes.
> 
> This means there are no standard locations where the FooConfig.cmake files
> are searched ?
> That's basically the same problem, the file has to be installed in some 
> place where it is found by cmake.
> I think it doesn't really matter whether these are FindFoo.cmake or 
> FooConfig.cmake or SomeMacro.cmake files.

Ok, we need a solution here.
Now that cmake is going to enter the "center stage" :-) things are going to change in this regard.
Until now cmake comes with FindFoo.cmake modules for all other software packages. 
Once other software packages will also use cmake as their native buildsystem it will be better if these projects deliver the required cmake files themselves, be it FindFoo.cmake or FooConfig.cmake files.
In KDE we have now already two "independent" software packages:
kdewin32 and qtdbus, which both use cmake as their native build system, which are both independent from KDE and which both have to be installed before starting to compile KDE (i.e. kdelibs).
Now in kdelibs we need a way to find kdewin32 and qtdbus.
For kdewin32 this wouldn't be a big problem. For qtdbus there are more issues. It features some cmake macros for code generation (QTDBUS_ADD_INTERFACES()). These are used when building qtdbus itself and also when compiling software which uses qtdbus. So qtdbus should install the cmake files which contain these macros.
Requiring every user to manually adjust KDEWIN32_Dir and QTDBUS_Dir is not really an option for the long term.

Currently one option would be possible to install these files directly into the cmake system module directory. 
This has drawbacks:
-the user has to be root in order to install them, which is not always the case
-the files would be intermixed with the original cmake module files
-these files would be able to overwrite original cmake module files 
-the admin might prefer to have these files on another partition, for backup etc.

So I suggest to extend cmake so that:
-at first it searches CMAKE_MODULE_PATH
-*NEW* then it searches $(HOME)/.CMake/Modules
-*NEW* then it searches ${CMAKE_ROOT}/MoreModules (or Custom/ or 3rdParty/ or ...)
-then it searches ${CMAKE_ROOT}/Modules/

AFAICT this would be fully backwards compatible.
There still would be the problem that two different projects would be able to install two files with the same name and so overwrite the file of the other project.
It would also be possible to introduce an environment variable (as PKG_CONFIG_DIR) to look for the files, but this would add an extra step which cam go wrong.

What do you think ?

Bye
Alex

-- 


Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer