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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
