I built separate package libkipi 2.0.0 using sources from digikam-3.0.0-beta1 and then built digikam-3.0.0-beta1, gwenvew and ksnapshot (using Victor Dodon patches) but no one of plugins found (all of them installed) in all apps. There is shown in digikam KIPI plugins settings: "Kipi Plugins: 3.0.0-beta1, Libkipi: 2.0.0", "No KIPI plugin installed". See libkipi and digikam build logs: http://kojipkgs.fedoraproject.org//packages/libkipi/4.9.50/1.fc19/data/logs/x86_64/build.log http://kojipkgs.fedoraproject.org//packages/digikam/3.0.0/0.1.beta1a.fc19/data/logs/x86_64/build.log Reproducible: Always
run kdebugdialog and turn on kipiplugins and KIPI debug space. run digiKam fro a console. What do you see in trace ? Gilles Caulier
digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Экспорт в iPod" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Panorama" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Экспорт в Rajce.net" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Многофункциональное слайд-шоу" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Удаление эффекта «красных глаз»" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Смешивание экспозиции" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Печать изображений" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Экспорт в Flickr, 23 и Zooomr" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Календарь" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Экспорт в Piwigo" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Импорт и экспорт в SmugMug" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "JPEG без потерь качества" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Экспорт на Викисклад" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Импорт и экспорт через KIO" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Программа просмотра изображений" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Photivo Integration" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Экспорт в Shwup" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Экспорт во Flash" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Экспорт в VKontakte.ru" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Сканирование изображений" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Экспорт в снимки экрана Debian" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Отправка изображений" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Пакетная обработка изображений" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Экспорт в Imgur" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Синхронизация с GPS" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Экспорт в веб-альбомы Picasa" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "VideoSlideShow" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Настройка даты и времени" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Экспорт в Яндекс.Фотки" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Imageshack Export" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Photo Layouts Editor" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Галерея в HTML" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Экспорт в KML" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "DLNAExport" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Редактирование метаданных" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Преобразование в DNG" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Экспорт в удалённую галерею" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Импорт и экспорт в Facebook" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Конвертор цифровых негативов (RAW)" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load. digikam(1550)/KIPI (loading) KIPI::PluginLoader::init: Plugin "Экспорт в сеть обмена мгновенными сообщениями" has a SO version ( 0 ) which is different than libkipi ABI version ( 10 ). Refusing to load.
Sound like your plugins have not been compiled with libkipi 2.0.0, provided by digiKam Software collection 3.0.0 Are you installed libkipi 2.0.0 on your system ? Which digiKam SC 3.0.0 tarball have you used exactly ? Gilles Caulier
You can see in log that libkipi-4.9.50 (2.0.0) was installed at build time (and it installed in system running digikam-3.0.0) http://kojipkgs.fedoraproject.org//packages/digikam/3.0.0/0.1.beta1a.fc19/data/logs/x86_64/root.log And in build log you can see -- libkipi: Found version 2.0.0 (required: 2.0.0) http://kojipkgs.fedoraproject.org//packages/digikam/3.0.0/0.1.beta1a.fc19/data/logs/x86_64/build.log I used newest tarball http://ftp.kde.org/unstable/digikam/digikam-3.0.0-beta1a.tar.bz2
Look plugins desktop files installed with all kipi plugins : [root@localhost kipi-plugins]# pwd /mnt/data/Devel/GIT/3.x/build/extra/kipi-plugins [root@localhost kipi-plugins]# make install/fast |grep .desktop -- Up-to-date: /usr/share/applications/kde4/kipiplugins.desktop -- Up-to-date: /usr/share/kde4/services/kipiplugin_timeadjust.desktop -- Up-to-date: /usr/share/kde4/services/kipiplugin_jpeglossless.desktop -- Up-to-date: /usr/share/kde4/services/kipiplugin_rawconverter.desktop -- Up-to-date: /usr/share/kde4/services/kipiplugin_metadataedit.desktop -- Up-to-date: /usr/share/kde4/services/kipiplugin_sendimages.desktop -- Up-to-date: /usr/share/kde4/services/kipiplugin_flashexport.desktop -- Up-to-date: /usr/share/kde4/services/kipiplugin_flickrexport.desktop -- Up-to-date: /usr/share/kde4/services/kipiplugin_galleryexport.desktop -- Up-to-date: /usr/share/kde4/services/kipiplugin_piwigoexport.desktop -- Up-to-date: /usr/share/kde4/services/kipiplugin_kioexportimport.desktop -- Up-to-date: /usr/share/kde4/services/kipiplugin_picasawebexport.desktop -- Up-to-date: /usr/share/kde4/services/kipiplugin_smug.desktop -- Up-to-date: /usr/share/kde4/services/kipiplugin_printimages.desktop ... etc... [root@localhost kipi-plugins]# cat /usr/share/kde4/services/kipiplugin_timeadjust.desktop [Desktop Entry] Name=TimeDateAdjust Name[ar]=ضبطالتاريخالوقت Name[ast]=TimeDateAdjust Name[bg]=Нагласяване на дата и час Name[bs]=Podešavanje vremena i datuma Name[ca]=TimeDateAdjust Name[ca@valencia]=TimeDateAdjust Name[cs]=Úprava data a času Name[da]=TimeDateAdjust Name[de]=Zeit/Datum einstellen Name[el]=TimeDateAdjust Name[en_GB]=TimeDateAdjust Name[es]=Ajustar fecha y hora Name[et]=Aja kohendamine Name[eu]=Ordua eta data doitzea Name[fi]=Päiväyksen tarkistus Name[fr]=Ajuster l'heure et la date Name[ga]=TimeDateAdjust Name[gl]=TimeDateAdjust Name[he]=שינוי תאריך ושעה Name[hne]=टाइम-डेट-एडजस्ट Name[hu]=Dátum és idő beállítás Name[is]=TimeDateAdjust Name[it]=Regolazione di data e ora Name[ja]=TimeDateAdjust Name[km]=លៃតម្រូវកាលបរិច្ឆេទ/ពេលវេលា Name[ko]=TimeDateAdjust Name[lv]=Laika un datuma korekcija Name[nb]=TimeDateAdjust Name[nds]=TietDatumtopassen Name[nl]=Tijd/DatumAanpassen Name[pa]=ਟਾਈਮ ਮਿਤੀ ਅਡਜੱਸਟ Name[pl]=DostrajanieCzasuDaty Name[pt]=Ajuste de Data e Hora Name[pt_BR]=Ajuste de data e hora Name[ro]=Ajustare dată și oră Name[ru]=Настройка даты и времени Name[sk]=Oprava dátumu a času Name[sl]=TimeDateAdjust Name[sq]=Kohë Datë Rregullo Name[sv]=Justera datum och tid Name[th]=ปรับแก้ค่าวันที่และเวลาของภาพ Name[tr]=Tarih Saat Ayarla Name[uk]=TimeDateAdjust Name[x-test]=xxTimeDateAdjustxx Name[zh_CN]=时间数据调整 Name[zh_TW]=時間日期調整 Comment=A tool to adjust date and time Comment[ast]=Una ferramienta p'axustar la data y la hora Comment[bg]=Инструмент за нагласяване на датата и часа Comment[bs]=Alat za podešavanje datuma i vremena Comment[ca]=Una eina per a ajustar la data i l'hora Comment[ca@valencia]=Una eina per a ajustar la data i l'hora Comment[cs]=Nástroj pro úpravu data a času Comment[da]=Et værktøj til at justere dato og tidspunkt Comment[de]=Ein Werkzeug, um Datum und Zeit zu justieren. Comment[el]=Εργαλείο ρύθμισης ημερομηνίας και ώρας Comment[en_GB]=A tool to adjust date and time Comment[es]=Una herramienta para ajustar la fecha y hora Comment[et]=Tööriist kuupäeva ja kellaaja kohandamiseks Comment[eu]=Ordua eta data doitzeko tresna Comment[fr]=Outil pour ajuster la date et l'heure Comment[ga]=Uirlis a choigeartaíonn an dáta agus an t-am Comment[gl]=Unha ferramenta para axustar a data e a hora Comment[he]=כלי לשינוי תאריך ושעה Comment[hne]=तारीक अउ समय ल एडजस्ट करे के एक औजार Comment[hu]=Egy eszköz dátum és idő beállításához Comment[is]=Verkfæri til að breyta dagsetningu og tímamerkjum mynda Comment[it]=Uno strumento per regolare la data e l'ora Comment[ja]=日付と時刻を調整するツール Comment[km]=ឧបករណ៍ត្រូវលៃតម្រូវកាលបរិច្ឆេទ និងពេលវេលា Comment[lv]=Rīks laika un datuma koriģēšanai Comment[nb]=Et verktøy for å justere dato og klokkeslett Comment[nds]=En Warktüüch, mit dat sik Datum un Tiet topassen laat Comment[nl]=Een hulpmiddel voor het aanpassen van datum en tijd Comment[pa]=ਮਿਤੀ ਅਤੇ ਟਾਈਮ ਅਡਜੱਸਟ ਕਰਨ ਲਈ ਇੱਕ ਟੂਲ Comment[pl]=Narzędzie do dostrajania daty i czasu Comment[pt]=Uma ferramenta para ajustar a data e hora Comment[pt_BR]=Uma ferramenta para ajustar a data e a hora Comment[ro]=O unealtă pentru ajustarea datei și orei Comment[ru]=Инструмент для настройки даты и времени Comment[sk]=Nástroj na opravu dátumu a času Comment[sl]=Orodje za nastavljanje datuma in časa Comment[sq]=Një mjet për të rregulluar datën dhe orën Comment[sv]=Ett verktyg för att justera datum och tid Comment[th]=เครื่องมือในการปรับแก้วันที่และเวลาของภาพ Comment[tr]=Tarihi ve saati ayarlamak için bir araç Comment[uk]=Інструмент для налаштування дати і часу Comment[x-test]=xxA tool to adjust date and timexx Comment[zh_CN]=一个调整日期和时间的工具 Comment[zh_TW]=調整日期和時間的工具 Type=Service Icon=timeadjust ServiceTypes=KIPI/Plugin X-KDE-Library=kipiplugin_timeadjust author=Gilles Caulier, caulier dot gilles at gmail dot com X-KIPI-ReqFeatures=ImagesHasTime X-KIPI-PluginCategories=Image X-KIPI-BinaryVersion=10 [root@localhost kipi-plugins]# Look like you must see X-KIPI-BinaryVersion property set to "10". It's the SO name set by likipi during compilation. Gilles Caulier
/usr/share/kde4/services/kipiplugin_acquireimages.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_advancedslideshow.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_batchprocessimages.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_calendar.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_debianscreenshots.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_dlnaexport.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_dngconverter.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_expoblending.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_facebook.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_flashexport.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_flickrexport.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_galleryexport.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_gpssync.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_htmlexport.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_imageshackexport.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_imageviewer.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_imgurexport.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_ipodexport.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_jpeglossless.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_kioexportimport.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_kmlexport.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_kopete.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_metadataedit.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_panorama.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_photivointegration.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_photolayoutseditor.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_picasawebexport.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_piwigoexport.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_printimages.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_rajceexport.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_rawconverter.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_removeredeyes.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_sendimages.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_shwup.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_smug.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_timeadjust.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_videoslideshow.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_vkontakte.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_wikimedia.desktop:X-KIPI-BinaryVersion= /usr/share/kde4/services/kipiplugin_yandexfotki.desktop:X-KIPI-BinaryVersion=
Nucleo, To be able to compile kipi-plugins outside digiKam SC, you need to use common FindKIPI cmake script from digiKam, not script provided by KDELibs. This script will set SO name in desktop file properly. Look this file : https://projects.kde.org/projects/extragear/graphics/digikam/digikam-software-compilation/repository/revisions/master/entry/cmake/modules/FindKipi.cmake ... Its' provided into digiKam SC 3.0.0 tarball Gilles Caulier
kipi-plugins not outside Digikam SC, both digikam and kipi-plugins built from one tarball. Only libkipi built as separate package.
Well, which cmake script is used to detect libkipi if it come a separated way. the digiKam SC libkipi detect script is not installed in the system and not used in case of and external version of libkipi is used ! This script must be installed on your system, else this SO name value will be not set. If you package libkipi outside SC tarball, this script must be included with, else... Gilles Caulier
Only one FindKipi.cmake from kdelibs can be installed in system. But looks like there was no any changes in kdelibs: http://quickgit.kde.org/index.php?p=kdelibs.git&a=history&h=af9855dc23456784f085a9587cad71fb85e125cf&f=cmake%2Fmodules%2FFindKipi.cmake
Is new FindKipi.cmake from digikam-3.0.0 can work with old libkipi?
The script from KDELibs is not yet updated. It still in my TODO list. This is why it doesn't work. The new script will be compatible with older kipi-plugins version of course... Gilles Caulier
Created attachment 74092 [details] New libkipi cmake found script for KDELibs
Alexander, can you review new FindKipi.cmake from comment #13, and push it to kdelibs?
The same result ffter updating FindKipi.cmake in kdelibs and rebuilding digikam, there are again X-KIPI-BinaryVersion=
I can confirm nucleo's findings, though I'm at a loss why that is so. Using the patched FindKipi.cmake (and deleting digikam's unpatched bundled copy), cmake output includes: .... -- Kipi library SO binary version: 10 but KIPI_SO_VERSION isn't recorded into CMakeCache.txt nor is it's value propogated to kipi's .desktop files.
Created attachment 74178 [details] New libkipi cmake found script for KDELibs (version 2) I found a problem with minimal version of libkipi checked. It must be 2.0.0, not 1.2.0 Gilles Caulier
To all, I recently communicate with another digiKam/Kipi-plugins developer (Smit Mehta) who has see exactly the same problem reported here. The lead problem is another version of libkipi been installed to the system (and older one), and FindKipi.cmake script been lost if 1.2.0 version is checked. My last version of FindKipi.cmake script attached to this entry fix the problem. It require libkipi 2.0.0, which is the current one available in git/master. Gilles Caulier
(In reply to comment #18) > The lead problem is another version of libkipi been installed to the system (and older one), > and FindKipi.cmake script been lost if 1.2.0 version is checked. This builds http://koji.fedoraproject.org/koji/buildinfo?buildID=355776 done in mock where impossible to install different libkipi versions. digikam package have requirement which version should be installed at build time, so only needed libkipi 2.0.0 was installed in build root. > My last version of FindKipi.cmake script attached to this entry fix the > problem. It require libkipi 2.0.0, which is the current one available in > git/master. Last FindKipi.cmake still compatible with older libkipi versions? Current libkipi git/master differs from released with digikam-3.0.0-beta1 in one commit with zh_TW translation.
I replaced kdelibs FindKipi.cmake with new one from comment 17, but still have the same problem with desktop files: X-KIPI-BinaryVersion= after rebuilding digikam.
I think I found the problem, neither KIPI_DEFINITIONS or KIPI_SO_VERSION variables are marked to be cached, so their values to not get saved in CMakeCache.txt. (what's odd is how this worked for anyone without this) I'll post a patch shortly after a little more testing
A patch to FindKipi.cmake something like: diff -u FindKipi.cmake.orig FindKipi.cmake --- FindKipi.cmake.orig 2012-09-26 07:55:01.696543651 -0500 +++ FindKipi.cmake 2012-09-26 07:57:18.285029793 -0500 @@ -75,7 +75,7 @@ FIND_LIBRARY(KIPI_LIBRARIES NAMES libkipi PATHS ${KIPI_LIBRARY_DIRS} ${LIB_INSTALL_DIR} ${KDE4_LIB_DIR}) FIND_PATH(KIPI_INCLUDE_DIR NAMES libkipi/version.h PATHS ${KIPI_INCLUDE_DIRS} ${INCLUDE_INSTALL_DIR} ${KDE4_INCLUDE_DIR}) SET(KIPI_VERSION_H_FILENAME "${KIPI_INCLUDE_DIR}/libkipi/version.h") - SET(KIPI_DEFINITIONS ${KIPI_CFLAGS}) + SET(KIPI_DEFINITIONS ${KIPI_CFLAGS} CACHE STRING "Kipi defintions") INCLUDE(FindPackageHandleStandardArgs) FIND_PACKAGE_HANDLE_STANDARD_ARGS(KIPI DEFAULT_MSG KIPI_LIBRARIES KIPI_INCLUDE_DIR) @@ -95,9 +95,10 @@ STRING(REGEX REPLACE ".*static +const +int +kipi_binary_version += ([^ ;]+).*" "\\1" - KIPI_SO_VERSION + KIPI_SO_VERSION_FOUND "${KIPI_VERSION_H_CONTENT}" ) + SET(KIPI_SO_VERSION ${KIPI_SO_VERSION_FOUND} CACHE STRING "libkipi so version") MESSAGE(STATUS "Kipi library SO binary version: ${KIPI_SO_VERSION}") ENDIF(NOT KIPI_SO_VERSION)
Created attachment 74182 [details] New libkipi cmake found script for KDELibs (version 3) This new version of FindKipi.cmake script include previous Rex patch, and add a new input option to force lib version to find on system. Default is 1.2.0 for compatibilty ask by Nucleo, if root script do not set this value. Gilles Caulier
Nucleo, I also patched a little bit root cmake script from kipi-plugins and digiKam from git/master, about libkipi detection. But this version of FindKipi.cmake must work with digiKam SC 3.0.0-beta1 tarball. Gilles Caulier
Why don't you use CMake (≥ 2.6)'s built-in support for requiring a minimum version? find_package(Kipi 2.0.0 REQUIRED) automatically sets: Kipi_FIND_VERSION to "2.0.0" Kipi_FIND_VERSION_MAJOR to 2 Kipi_FIND_VERSION_MINOR to 0 Kipi_FIND_VERSION_PATCH to 0 The use of custom *_MIN_VERSION options has been deprecated for years. See the comments about KDE_MIN_VERSION in FindKDE4Internal.cmake and the documentation of find_package in man:cmake.
X-KIPI-BinaryVersion=10 now in .desktop files after digikam rebuild with rdieter's fixes from comment 22.
Thanks Nucleo... Kevin, i will take a look tomorrow to a more elegant solution to pass version id as argument to the script... Gilles Caulier
Created attachment 74208 [details] New libkipi cmake found script for KDELibs (version 4) This new version of FindKipi.cmake script use cmake argument to check required libkipi version, as suggested by Kevin Kofler from comment #25 Gilles Caulier
Sorry for chiming in so late: I think Alex does not watch Bugzilla all that often, so I really suggest sending these changes to FindKipi via ReviewBoard to the buildsystem group. A few things I could notice at a quick glance: these days I don't think we need to avoid pkg-config on WIN32, and its values should be used as HINTS to the actual find_*() calls. All those MESSAGE() calls may be unnecessary, as well as the handling of _FIND_QUIETLY, which should be done by FIND_PACKAGE_HANDLE_STANDARD_ARGS().
*** Bug 307619 has been marked as a duplicate of this bug. ***
Well, I'm just going to chime in here to note that I almost reported a duplicate to this bug. I agree that the kdelibs FindKipi.cmake needs to be fixed, but that won't be available until KDE Platform 4.10. CMake has the capability of installing "config" files to record appropriate package installation metadata directly, and my understanding is that this is preferred over using FindFoo.cmake-style code. Could libkipi be modified to install the appropriate CMake config metadata and kipi-plugins be modified to use that if present and only use kdelibs's FindKipi as a fallback? For more details see http://www.cmake.org/pipermail/cmake/2010-November/040977.html (mail by our hero Alex Neundorf), http://www.cmake.org/Wiki/CMake/Tutorials/Packaging#Packaging_and_Exporting (giving a very very simple example of making a package config file and using it later). Or, you can ask on the kde-buildsystem mailing list. Even if it works in Digikam SC, other KDE graphics apps use libkipi and kipi-plugins and so it is important that the non-SC variants are able to work without bumping the kdelibs version requirement for them all recursively. ;-) In any event I *highly* recommend to have the current kipi-plugins abort compilation at the CMake stage if there is no binary SO version set but a libkipi is detected that requires that (e.g. 2.0.0 or later detected). Thanks!
Why can't we just fix FindKipi.cmake in 4.9.3? (In fact I'm tempted to just commit that.)
Kevin: No reason we can't do it in 4.9.3 (though it still comes too late). I'm working on making a patch to implement my own suggestion, hopefully we can update libkipi and the various users of it. libkipi seems to be the harder one to fix, once it provides the config information CMake should pick it up almost automatically for users just doing "find_package(Kipi)" if I understand the package config scheme correctly.
Created attachment 74470 [details] Patch to modify libkipi to install CMake config and version metadata This patch uses the example of KActivities and the "KDE Examples" git repo at http://quickgit.kde.org/?p=kdeexamples.git&a=tree&hb=HEAD&f=buildsystem/HowToInstallALibrary to provide the needed CMake magic for libkipi to store its build configuration and versioning information. Specifically, the libkipi soversion is also stored in the config info so it can be read later. This information can be used by find_package() later to do version detection and to read in configuration variables (such as the soversion). It may be required to call find_package() with the NO_MODULE option to force usage of the config files instead of FindKipi.cmake. An example patch for kipi-plugins will follow.
Created attachment 74471 [details] Example patch for kipi-plugins to find and use libkipi with CMake config metadata (instead of FindKipi) This patch gives an example of the kind of CMake changes needed for a libkipi user to find libkipi if the CMake config storage patch is adopted. I removed the REQUIRED option to allow configuration to continue even if the required package isn't present (the CMake docs seem to imply configuration would fail immediately, which would prevent the nice error messages from being shown). I did have to use NO_MODULE to force the Config metadata to be searched for instead of using FindKipi immediately. find_package() unfortunately does not seem to set the same variables when using Config metadata. So instead of KIPI_FOUND I use KIPI_VERSION to detect if a valid version of KIPI was found. The CMake docs imply say that KIPI_CONFIG should be set to the full path of the chosen CMake config metadata, but I couldn't get that to work, so I used KIPI_VERSION throughout. Other than that, the process was fairly smooth sailing (and most importantly, the config metadata *did* solve the issue of the soversion being available. I've confirmed that the build fills in the soversion properly with this patch and the libkipi patch applied).
> find_package() unfortunately does not seem to set the same variables when using Config metadata. > So instead of KIPI_FOUND I use KIPI_VERSION to detect if a valid version of KIPI was found. Can't you just set KIPI_FOUND in KipiConfig.cmake?
And I think the reason why KIPI_FOUND and KIPI_CONFIG are not being defined is that they're called Kipi_FOUND and Kipi_CONFIG instead. Case matters!
(In reply to comment #37) > And I think the reason why KIPI_FOUND and KIPI_CONFIG are not being defined > is that they're called Kipi_FOUND and Kipi_CONFIG instead. Case matters! I'll check on that, but I will point out that I experimented with case-sensitivity with Kipi_VERSION and KIPI_VERSION, which *is* case-insensitive. I may have extrapolated too much from that finding...
I wonder why FindKipi.cmake is in kdelibs and not in libkipi. I used the following work around: I put Gilles' FindKipi.cmake in kipi-plugins/cmake/modules/ as a local cmake file is preferred over the system's one.
This is an old story (few year ago), when we have integrated libkipi to kdegraphics and port libkipi to cmake. Initially, this script come from libkipi as well, and Laurent Montel have moved it to KDELibs (I don't remember exactly why...). It's the same for FindKexiv2 and FindKdcraw cmake scripts, which detect digiKam shared libs hosted to kdegraphics. It more logic for me to host cmake find script to library. But perhaps i forget something here... Gilles Caulier
(In reply to comment #40) > > It more logic for me to host cmake find script to library. But perhaps i > forget something here... That is my opinion too. If a library uses CMake it should also provide the find script. The question is now when this could be changed, KDE 4.10 or 5? Gilles, why you don't update the find script in kdelibs 4.9 and .10? That would at least help people building KDE from source. Or put the updated version in kipi-plugins.
Andre, I delegate the script validation task to the student who have work this summer on new libkipi API (Victor Dodon). I recently talk with him, and he plan to work on it soon (before KDE 4.10) Gilles Caulier
That sounds good, thanks.
The library should be providing a Config script, really, rather than a Find script. Find scripts should generally be there whether or not the library is installed, but Config scripts should only be there if the library is installed.
It won't make much of a difference in practice (a Config script and a library-provided Find script will have basically the same effect), but yes, conceptually, it doesn't make much sense for a library to ship FindMyself.cmake. ;-)
> --- Comment #44 from Alex Merry <kde@randomguy3.me.uk> --- > The library should be providing a Config script, really, rather than a Find > script. Find scripts should generally be there whether or not the library > is installed, Yep, I forgot about optional dependencies. In that case the find script must be there but not the library. > but Config scripts should only be there if the library is installed. Do you mean pkg config files?
(In reply to comment #46) > > but Config scripts should only be there if the library is installed. > > Do you mean pkg config files? No, I mean like http://www.cmake.org/Wiki/CMake/Tutorials/Packaging#Package_Configuration_Files
> --- Comment #47 from Alex Merry <kde@randomguy3.me.uk> --- > > > but Config scripts should only be there if the library is installed. > > > > Do you mean pkg config files? > > No, I mean like > http://www.cmake.org/Wiki/CMake/Tutorials/Packaging#Package_Configuration_Files Ah, I didn't know that, thanks for the info.
(In reply to comment #45) > It won't make much of a difference in practice (a Config script and a > library-provided Find script will have basically the same effect), but yes, > conceptually, it doesn't make much sense for a library to ship > FindMyself.cmake. ;-) It does make a difference. A Config.cmake file is searched on the system by cmake, while a Find-module must be provided by the project (or cmake). A Config.cmake file contains information about one installed instance of the project, while a Find-module contains descriptions how to search for installed files of a project. Alex
> It does make a difference. Not really: > A Config.cmake file is searched on the system by cmake, while a Find-module must be provided by the project (or cmake). A Find-module dumped to somewhere within the search path for Find-modules by the library (e.g., for anything requiring the KDE4 package, %{_kde4_appsdir}/cmake/modules is such a path, and that's where KDE libraries tend to drop their Find-modules) will be found on the system just like a Config.cmake file. > A Config.cmake file contains information about one installed instance of the project, while a Find-module contains descriptions how to search for installed files of a project. Conceptually, yes. In practice, I can write a Config.cmake file which uses the exact same find_* commands as a Find-module (and that's effective if I don't want to bother how to fill in hardcoded paths properly; in fact, we do this for OkularConfig.cmake in Fedora: http://pkgs.fedoraproject.org/cgit/okular.git/tree/kdegraphics-4.5.80-OkularConfig-dont-hardcode-paths.patch because your hardcoded paths are wrong; FWIW, I still think this patch should be upstreamed, because as is, the Okular libraries cannot be found on Fedora if you build Okular from upstream sources), or conversely, I can write a Find-module (installed by a library to a systemwide path, see above) which works just like a Config.cmake file (i.e. has all the paths filled in).
(In reply to comment #50) > > It does make a difference. > > Not really: > > > A Config.cmake file is searched on the system by cmake, while a Find-module must be > > provided by the project (or cmake). > > A Find-module dumped to somewhere within the search path for Find-modules by > the library (e.g., for anything requiring the KDE4 package, > %{_kde4_appsdir}/cmake/modules is such a path, That's true (and I'm not sure this was such a great idea back then). Nevertheless, CMAKE_MODULE_PATH is intended to be set by the using project itself, and CMake looks only in these directories for Find-module, not in other places. > and that's where KDE libraries tend to drop their Find-modules) will be found on the system > just like a Config.cmake file. Only kdelibs should install Find-modules, that other modules do that too is really not good. I realized that a bit late. > > A Config.cmake file contains information about one installed instance of the project, while a > > Find-module contains descriptions how to search for installed files of a project. > > Conceptually, yes. In practice, I can write a Config.cmake file which uses > the exact same find_* commands as a Find-module Yes, but you shouldn't. > (and that's effective if I > don't want to bother how to fill in hardcoded paths properly; in fact, we do > this for OkularConfig.cmake in Fedora: > http://pkgs.fedoraproject.org/cgit/okular.git/tree/kdegraphics-4.5.80- > OkularConfig-dont-hardcode-paths.patch because your hardcoded paths are > wrong; Why/how are they wrong ? Alex
http://mail.kde.org/pipermail/release-team/2010-November/004228.html
(In reply to comment #52) > http://mail.kde.org/pipermail/release-team/2010-November/004228.html Ah, yes, this file indeed is too simple. It needs to handle its actual install location properly. That a Config.cmake file is not portable is no problem, they are not intended to be portable, they are intended to just provide the information about the installed binary library.
Well yes, if the path gets filled in at install time, there's no problem, it's hardcoding it in advance which doesn't work. The problem with filling it in at install time the obvious way is of course that the kdewin folks won't like it because users of that broken OS just move around their binaries to arbitrary directories.
(In reply to comment #54) > Well yes, if the path gets filled in at install time, there's no problem, > it's hardcoding it in advance which doesn't work. > > The problem with filling it in at install time the obvious way is of course > that the kdewin folks won't like it because users of that broken OS just > move around their binaries to arbitrary directories. This also applies to OSX, where users can install their stuff anywhere (depending on the package type). Well, since 2.8.8 cmake comes with a macro configure_package_config_file(), which should be used to configure Config.cmake files, and which takes care of this too.
*** Bug 311812 has been marked as a duplicate of this bug. ***
Everyone, it would be awesome if this could be fixed somehow before 4.10 comes out. (We're at RC1 now.) (Especially since kipi-plugins-3 is supposed to come out together with and supplement KDE 4.10.) It seems there are functional and updated copies of FindKipi.cmake, FindKdcraw.cmake and FindKexiv2.cmake in the Digikam 3.0 tarball, while kdelibs(-4.9.90) installs defunct ones from 2008. Are there any serious arguments against updating the copies in kdelibs?
See also bug 311936. I consider this a release blocker.
(In reply to comment #58) > See also bug 311936. I consider this a release blocker. After talking to Albert Astals Cid, added this as a release blocker at http://community.kde.org/KDE/KDE_SC_4.10_release
> It seems there are functional and updated copies of FindKipi.cmake, > FindKdcraw.cmake and FindKexiv2.cmake in the Digikam 3.0 tarball, while > kdelibs(-4.9.90) installs defunct ones from 2008. > > Are there any serious arguments against updating the copies in kdelibs? It seems that it's more complicated. I patched the new FindKipi.cmake from digikam-3 tarball into the kdelibs-4.9.95 files; then, gwenview and ksnapshot 4.9.95 fail in cmake phase with CMake Error at /usr/share/apps/cmake/modules/FindKipi.cmake:24 (IF): if given arguments: "STREQUAL" "" Unknown arguments specified Call Stack (most recent call first): /usr/share/apps/cmake/modules/MacroOptionalFindPackage.cmake:32 (find_package) CMakeLists.txt:42 (macro_optional_find_package)
> It seems that it's more complicated. I patched the new FindKipi.cmake from > digikam-3 tarball into the kdelibs-4.9.95 files; then, gwenview and > ksnapshot 4.9.95 fail in cmake phase with [...] After applying the following trivial patch to the digikam-3 FindKipi.cmake and adding it to kdelibs, gwenview and ksnapshot also build fine: From 8d4db04a42f95856fa181acfa2798e9af3d3442e Mon Sep 17 00:00:00 2001 From: "Andreas K. Huettel (dilfridge)" <mail@akhuettel.de> Date: Fri, 21 Dec 2012 23:55:32 +0100 Subject: [PATCH] Fix quoting --- cmake/modules/FindKipi.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmake/modules/FindKipi.cmake b/cmake/modules/FindKipi.cmake index 82c9718..5024450 100644 --- a/cmake/modules/FindKipi.cmake +++ b/cmake/modules/FindKipi.cmake @@ -21,7 +21,7 @@ # Redistribution and use is allowed according to the terms of the BSD license. # For details see the accompanying COPYING-CMAKE-SCRIPTS file. -IF(${Kipi_FIND_VERSION} STREQUAL "") +IF("${Kipi_FIND_VERSION}" STREQUAL "") SET(Kipi_FIND_VERSION "1.2.0") MESSAGE(STATUS "No Kipi library version required. Check default version : ${Kipi_FIND_VERSION}") ELSE() -- 1.8.0.2
(In reply to comment #61) > --- a/cmake/modules/FindKipi.cmake > +++ b/cmake/modules/FindKipi.cmake > -IF(${Kipi_FIND_VERSION} STREQUAL "") > +IF("${Kipi_FIND_VERSION}" STREQUAL "") I can confirm this. Adding this patch makes gwenview and ksnapshot compile current 4.10 branch versions
Git commit 1ee13fb1fc22b1d53b52da2884a7765164984052 by Victor Dodon. Committed on 26/12/2012 at 22:43. Pushed by dodon into branch 'master'. Patch FindKipi.cmake to find new libkipi BUG: 307213 CCMAIL: caulier.gilles@gmail.com M +123 -106 cmake/modules/FindKipi.cmake http://commits.kde.org/kdelibs/1ee13fb1fc22b1d53b52da2884a7765164984052 diff --git a/cmake/modules/FindKipi.cmake b/cmake/modules/FindKipi.cmake index 13521e5..5024450 100644 --- a/cmake/modules/FindKipi.cmake +++ b/cmake/modules/FindKipi.cmake @@ -1,116 +1,133 @@ -# - Try to find the Kipi library +# Module that tries to find the Kipi library # -# If you have put a local version of libkipi into your source tree, -# set KIPI_LOCAL_DIR to the relative path to the local directory. +# Input values : # -# Once done this will define +# KIPI_LOCAL_DIR - If you have put a local version of libkipi into your source tree, +# set this variable to the relative path from the local directory. # -# KIPI_FOUND - system has libkipi -# KIPI_INCLUDE_DIR - the libkipi include directory -# KIPI_LIBRARIES - Link these to use libkipi +# Output values : +# +# KIPI_FOUND - System has libkipi +# KIPI_INCLUDE_DIR - The libkipi include directory +# KIPI_LIBRARIES - Link these to use libkipi # KIPI_DEFINITIONS - Compiler switches required for using libkipi +# KIPI_VERSION - The release version of the Kipi library +# KIPI_SO_VERSION - The binary SO version of the Kipi library # -# Copyright (c) 2008, Gilles Caulier, <caulier.gilles@gmail.com> +# Copyright (c) 2012, Victor Dodon <dodonvictor at gmail dot com> +# Copyright (c) 2012, Gilles Caulier <caulier dot gilles at gmail dot com> # # Redistribution and use is allowed according to the terms of the BSD license. # For details see the accompanying COPYING-CMAKE-SCRIPTS file. -if (KIPI_INCLUDE_DIR AND KIPI_LIBRARIES AND KIPI_DEFINITIONS) - - message(STATUS "Found Kipi library in cache: ${KIPI_LIBRARIES}") - - # in cache already - set(KIPI_FOUND TRUE) - -else (KIPI_INCLUDE_DIR AND KIPI_LIBRARIES AND KIPI_DEFINITIONS) - - message(STATUS "Check Kipi library in local sub-folder...") - - # Check if library is not in local sub-folder - - if (KIPI_LOCAL_DIR) - set (KIPI_LOCAL_FOUND TRUE) - else (KIPI_LOCAL_DIR) - find_file(KIPI_LOCAL_FOUND libkipi/kipi.h ${CMAKE_SOURCE_DIR}/libkipi ${CMAKE_SOURCE_DIR}/libs/libkipi NO_DEFAULT_PATH) - - if (KIPI_LOCAL_FOUND) - # Was it found in libkdcraw/ or in libs/libkdcraw? - find_file(KIPI_LOCAL_FOUND_IN_LIBS libkipi/kipi.h ${CMAKE_SOURCE_DIR}/libs/libkipi NO_DEFAULT_PATH) - if (KIPI_LOCAL_FOUND_IN_LIBS) - set(KIPI_LOCAL_DIR libs/libkipi) - else (KIPI_LOCAL_FOUND_IN_LIBS) - set(KIPI_LOCAL_DIR libkipi) - endif (KIPI_LOCAL_FOUND_IN_LIBS) - endif (KIPI_LOCAL_FOUND) - endif (KIPI_LOCAL_DIR) - - if (KIPI_LOCAL_FOUND) - # we need two include directories: because the version.h file is put into the build directory - # TODO KIPI_INCLUDE_DIR sounds like it should contain only one directory... - set(KIPI_INCLUDE_DIR ${CMAKE_SOURCE_DIR}/${KIPI_LOCAL_DIR} ${CMAKE_BINARY_DIR}/${KIPI_LOCAL_DIR}) - set(KIPI_DEFINITIONS "-I${CMAKE_SOURCE_DIR}/${KIPI_LOCAL_DIR}" "-I${CMAKE_BINARY_DIR}/${KIPI_LOCAL_DIR}") - set(KIPI_LIBRARIES kipi) - message(STATUS "Found Kipi library in local sub-folder: ${CMAKE_SOURCE_DIR}/${KIPI_LOCAL_DIR}") - set(KIPI_FOUND TRUE) - mark_as_advanced(KIPI_INCLUDE_DIR KIPI_LIBRARIES KIPI_DEFINITIONS) - - else (KIPI_LOCAL_FOUND) - - if (NOT WIN32) - message(STATUS "Check Kipi library using pkg-config...") - - # use pkg-config to get the directories and then use these values - # in the FIND_PATH() and FIND_LIBRARY() calls - include(UsePkgConfig) - - PKGCONFIG(libkipi _KIPIIncDir _KIPILinkDir _KIPILinkFlags _KIPICflags) - - if (_KIPILinkFlags) - # query pkg-config asking for a libkipi >= 0.2.0 - exec_program(${PKGCONFIG_EXECUTABLE} ARGS --atleast-version=0.2.0 libkipi RETURN_VALUE _return_VALUE OUTPUT_VARIABLE _pkgconfigDevNull ) - if (_return_VALUE STREQUAL "0") - message(STATUS "Found libkipi release >= 0.2.0") - set(KIPI_VERSION_GOOD_FOUND TRUE) - else (_return_VALUE STREQUAL "0") - message(STATUS "Found libkipi release < 0.2.0, too old") - set(KIPI_VERSION_GOOD_FOUND FALSE) - set(KIPI_FOUND FALSE) - endif (_return_VALUE STREQUAL "0") - else (_KIPILinkFlags) - set(KIPI_VERSION_GOOD_FOUND FALSE) - set(KIPI_FOUND FALSE) - endif (_KIPILinkFlags) - else (NOT WIN32) - set(KIPI_VERSION_GOOD_FOUND TRUE) - endif (NOT WIN32) - if (KIPI_VERSION_GOOD_FOUND) - set(KIPI_DEFINITIONS ${_KIPICflags}) - - find_path(KIPI_INCLUDE_DIR NAMES libkipi/version.h PATHS ${KDE4_INCLUDE_DIR} ${_KIPIIncDir}) - find_library(KIPI_LIBRARIES NAMES kipi PATHS ${KDE4_LIB_DIR} ${_KIPILinkDir}) - - if (KIPI_INCLUDE_DIR AND KIPI_LIBRARIES) - set(KIPI_FOUND TRUE) - endif (KIPI_INCLUDE_DIR AND KIPI_LIBRARIES) - endif (KIPI_VERSION_GOOD_FOUND) - if (KIPI_FOUND) - if (NOT Kipi_FIND_QUIETLY) - message(STATUS "Found libkipi: ${KIPI_LIBRARIES}") - endif (NOT Kipi_FIND_QUIETLY) - else (KIPI_FOUND) - if (Kipi_FIND_REQUIRED) - if (NOT KIPI_INCLUDE_DIR) - message(FATAL_ERROR "Could NOT find libkipi header files") - endif (NOT KIPI_INCLUDE_DIR) - if (NOT KIPI_LIBRARIES) - message(FATAL_ERROR "Could NOT find libkipi library") - endif (NOT KIPI_LIBRARIES) - endif (Kipi_FIND_REQUIRED) - endif (KIPI_FOUND) - - mark_as_advanced(KIPI_INCLUDE_DIR KIPI_LIBRARIES KIPI_DEFINITIONS) - - endif (KIPI_LOCAL_FOUND) - -endif (KIPI_INCLUDE_DIR AND KIPI_LIBRARIES AND KIPI_DEFINITIONS) +IF("${Kipi_FIND_VERSION}" STREQUAL "") + SET(Kipi_FIND_VERSION "1.2.0") + MESSAGE(STATUS "No Kipi library version required. Check default version : ${Kipi_FIND_VERSION}") +ELSE() + MESSAGE(STATUS "Kipi library version required : ${Kipi_FIND_VERSION}") +ENDIF() + +IF(KIPI_INCLUDE_DIR AND KIPI_LIBRARIES AND KIPI_DEFINITIONS AND KIPI_VERSION AND KIPI_SO_VERSION) + + IF(NOT Kipi_FIND_QUIETLY) + MESSAGE(STATUS "Found kipi library in cache ${KIPI_LIBRARIES}") + ENDIF(NOT Kipi_FIND_QUIETLY) + # Already in cache + SET(KIPI_FOUND TRUE) + +ELSE(KIPI_INCLUDE_DIR AND KIPI_LIBRARIES AND KIPI_DEFINITIONS AND KIPI_VERSION AND KIPI_SO_VERSION) + + IF(NOT Kipi_FIND_QUIETLY) + MESSAGE(STATUS "Check Kipi library in local sub-folder...") + ENDIF(NOT Kipi_FIND_QUIETLY) + + IF(KIPI_LOCAL_DIR) + FIND_FILE(KIPI_LOCAL_FOUND libkipi/version.h.cmake ${CMAKE_SOURCE_DIR}/${KIPI_LOCAL_DIR} NO_DEFAULT_PATH) + IF(NOT KIPI_LOCAL_FOUND) + MESSAGE(WARNING "KIPI_LOCAL_DIR specified as \"${KIPI_LOCAL_DIR}\" but libkipi could not be found there.") + ENDIF(NOT KIPI_LOCAL_FOUND) + ELSE(KIPI_LOCAL_DIR) + FIND_FILE(KIPI_LOCAL_FOUND libkipi/version.h.cmake ${CMAKE_SOURCE_DIR}/libkipi NO_DEFAULT_PATH) + IF(KIPI_LOCAL_FOUND) + SET(KIPI_LOCAL_DIR libkipi) + ENDIF(KIPI_LOCAL_FOUND) + + FIND_FILE(KIPI_LOCAL_FOUND libkipi/version.h.cmake ${CMAKE_SOURCE_DIR}/libs/libkipi NO_DEFAULT_PATH) + IF(KIPI_LOCAL_FOUND) + SET(KIPI_LOCAL_DIR libs/libkipi) + ENDIF(KIPI_LOCAL_FOUND) + ENDIF(KIPI_LOCAL_DIR) + + IF(KIPI_LOCAL_FOUND) + + SET(KIPI_INCLUDE_DIR "${CMAKE_SOURCE_DIR}/${KIPI_LOCAL_DIR}" "${CMAKE_BINARY_DIR}/${KIPI_LOCAL_DIR}") + SET(KIPI_DEFINITIONS "-I${CMAKE_SOURCE_DIR}/${KIPI_LOCAL_DIR}" "-I${CMAKE_BINARY_DIR}/${KIPI_LOCAL_DIR}") + SET(KIPI_LIBRARIES kipi) + IF(NOT Kipi_FIND_QUIETLY) + MESSAGE(STATUS "Found Kipi library in local sub-folder: ${CMAKE_SOURCE_DIR}/${KIPI_LOCAL_DIR}") + ENDIF(NOT Kipi_FIND_QUIETLY) + SET(KIPI_FOUND TRUE) + SET(KIPI_VERSION_H_FILENAME "${CMAKE_BINARY_DIR}/${KIPI_LOCAL_DIR}/libkipi/version.h") + + ELSE(KIPI_LOCAL_FOUND) + + IF(NOT WIN32) + IF(NOT Kipi_FIND_QUIETLY) + MESSAGE(STATUS "Check Kipi library using pkg-config...") + ENDIF(NOT Kipi_FIND_QUIETLY) + + INCLUDE(FindPkgConfig) + PKG_CHECK_MODULES(KIPI libkipi>=${Kipi_FIND_VERSION}) + ENDIF(NOT WIN32) + + FIND_LIBRARY(KIPI_LIBRARIES NAMES libkipi PATHS ${KIPI_LIBRARY_DIRS} ${LIB_INSTALL_DIR} ${KDE4_LIB_DIR}) + FIND_PATH(KIPI_INCLUDE_DIR NAMES libkipi/version.h PATHS ${KIPI_INCLUDE_DIRS} ${INCLUDE_INSTALL_DIR} ${KDE4_INCLUDE_DIR}) + SET(KIPI_VERSION_H_FILENAME "${KIPI_INCLUDE_DIR}/libkipi/version.h") + SET(KIPI_DEFINITIONS ${KIPI_CFLAGS} CACHE STRING "Kipi defintions") + + INCLUDE(FindPackageHandleStandardArgs) + FIND_PACKAGE_HANDLE_STANDARD_ARGS(KIPI DEFAULT_MSG KIPI_LIBRARIES KIPI_INCLUDE_DIR) + + ENDIF(KIPI_LOCAL_FOUND) + + IF(KIPI_FOUND) + + IF(NOT KIPI_VERSION) + FILE(READ "${KIPI_VERSION_H_FILENAME}" KIPI_VERSION_H_CONTENT) + STRING(REGEX REPLACE ".*static +const +char +kipi_version\\[\\] += +\"([^\"]+)\".*" "\\1" KIPI_VERSION "${KIPI_VERSION_H_CONTENT}") + MESSAGE(STATUS "Kipi library version: ${KIPI_VERSION}") + ENDIF(NOT KIPI_VERSION) + + IF(NOT KIPI_SO_VERSION) + FILE(READ "${KIPI_VERSION_H_FILENAME}" KIPI_VERSION_H_CONTENT) + STRING(REGEX REPLACE + ".*static +const +int +kipi_binary_version += ([^ ;]+).*" + "\\1" + KIPI_SO_VERSION_FOUND + "${KIPI_VERSION_H_CONTENT}" + ) + SET(KIPI_SO_VERSION ${KIPI_SO_VERSION_FOUND} CACHE STRING "libkipi so version") + MESSAGE(STATUS "Kipi library SO binary version: ${KIPI_SO_VERSION}") + ENDIF(NOT KIPI_SO_VERSION) + + UNSET(KIPI_VERSION_H_CONTENT) + UNSET(KIPI_VERSION_H_FILENAME) + ENDIF(KIPI_FOUND) + + IF(KIPI_FOUND) + MESSAGE(STATUS "libkipi: Found version ${KIPI_VERSION} (required: ${Kipi_FIND_VERSION})") + IF(${KIPI_VERSION} VERSION_LESS ${Kipi_FIND_VERSION}) + SET(KIPI_FOUND FALSE) + ELSE() + MARK_AS_ADVANCED(KIPI_INCLUDE_DIR KIPI_LIBRARIES KIPI_DEFINITIONS KIPI_VERSION KIPI_SO_VERSION) + ENDIF() + ELSE(KIPI_FOUND) + UNSET(KIPI_INCLUDE_DIR) + UNSET(KIPI_LIBRARIES) + UNSET(KIPI_DEFINITIONS) + UNSET(KIPI_VERSION) + UNSET(KIPI_SO_VERSION) + ENDIF(KIPI_FOUND) + +ENDIF(KIPI_INCLUDE_DIR AND KIPI_LIBRARIES AND KIPI_DEFINITIONS AND KIPI_VERSION AND KIPI_SO_VERSION)
Thanks for fixing this one, can you also look at related bug 311936? Does it also affect libkexiv2?
Do we need this in KDE/4.10 branch?
Created attachment 76067 [details] Patch to modify libkipi to install CMake config and version metadata (v2; include needed .cmake.in file) I forgot to add the required KipiConfig.cmake.in file in my original patch, which may still be useful for other similar reported bugs, so I'm resubmitting to correct.
I'm commiting this to 4.10, thanks to all the people involved for not answering my question, i will blame you if that was the wrong thing to do.
Git commit c42172dc6d3db8643aef08f0335bb82489808892 by Albert Astals Cid, on behalf of Victor Dodon. Committed on 26/12/2012 at 22:43. Pushed by aacid into branch 'KDE/4.10'. Patch FindKipi.cmake to find new libkipi CCMAIL: caulier.gilles@gmail.com (cherry picked from commit ba2bc578ef49679ef553402e50173794adfbdd9c) M +123 -106 cmake/modules/FindKipi.cmake http://commits.kde.org/kdelibs/c42172dc6d3db8643aef08f0335bb82489808892