[Kde-scm-interest] Re: kdegraphics - a few technical questions

[Andreas Pakulat]

On 13.01.11 09:54:07, Ian Monroe wrote:
> On Thu, Jan 13, 2011 at 09:46, Andreas Pakulat <apaku at gmx.de> wrote:
> > On 13.01.11 08:01:05, Ian Monroe wrote:
> >> On Thu, Jan 13, 2011 at 03:11, Esben Mose Hansen <kde at mosehansen.dk> wrote:
> >> > On Wednesday 12 January 2011 15:28:38 Marcel Wiesweg wrote:
> >> >> a) should CMake modules be moved up to kdelibs or down to the submodule
> >> >> that  needs them?
> >> >
> >> > Instead of uusing CMake modules, I have great experiences with using the
> >> > cmake-config system. Which means that it is each component that have the cmake
> >> > machinery. It also makes finding a library somewhat faster, and it is easier
> >> > to have multiple versions installed.
> >> >
> >> > I have seen a few of these in the KDE-source, so i believe it is in line with
> >> > the KDE mindset.
> >>
> >> Yep, all the libraries we write should provide a
> >> LibraryNameConfig.cmake instead of a FindLibraryName.cmake.
> >>
> >> Of course the issue is finding all the libraries we don't provide...
> >
> > Its not so much about what we provide vs. what we don't provide ourselves,
> > but more about wether the project for that library uses cmake to build its
> > code or not. In theory its perfectly possible to generate those
> > XXConfig.cmake files without using cmake as buildsystem, but its a lot
> > easier when cmake does this for you..
> >
> 
> Actually cmake doesn't really do anything for you. Its more like: its
> easier to provide the .cmake files if you even know they exist, which
> I'd say is true only for a subset of cmake users.

For just the FooConfig.cmake thats correct, but personally I'd always use
imported targets along with a FooConfig.cmake file and that means cmake
will take over the hard part of setting up the paths to the libraries and
you 'just' need to find the includes, data and binaries (if any).

Andreas

-- 
Keep it short for pithy sake.