I'm out

[Alexander Neundorf]

On Friday 23 August 2013, Alexander Neundorf wrote:
...
> Another nice thing of a standard variable would have been that those
> packages could be made more easy available to non-cmake buildsystems.
> Two years ago after Randa I added an option --find-package JPEG to cmake,
> so you can call cmake from the command line, it will search the given
> package, and print the link or compile arguments to stdout, so they can
> simply be used in a hand-written makefile or with autoconf etc.
> This turned out to work not really well, due to the non-conformity of the
> results of find_package().
> I was hoping that now with KDE frameworks we would produce a relatively big
> number of Config-files which would all set the standard _LIBRARIES and
> _INCLUDE_DIRS variables, and that by restricting the --find-package mode of
> cmake to work only on Config-files, I could get much better results, so
> that this would actually get real-world usable. I didn't start to work on
> this yet, but it seems reasonable to me. Now, if we simply use the
> imported targets directly, I can forget about that too.

What I forgot:

I also wanted to make use of e-c-m in kdelibs4, to reduce duplicated code, and 
to maintain only one set of cmake files, but as e-c-m is handled now, that's 
not possible. I mean, there is no released version, and it depends in latest 
cmake.

In my mind, e-c-m was an add-on to cmake, which happened to provide all the 
additional stuff KDE needs.
It is handled now as a KDE-"library", constantly being updated and no 
versioned dependencies. I was even thinking whether it could be moved to 
github, to make contributing by others easier.

Alex