Bug 315881 - cmake misplaces local KDE graphics components
Summary: cmake misplaces local KDE graphics components
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Portability-Cmake (show other bugs)
Version: 2.9.0
Platform: Debian stable Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-28 02:01 UTC by Sven Coenye
Modified: 2017-07-28 08:26 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.0.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Coenye 2013-02-28 02:01:03 UTC
When trying to compile on KDE installations older than 4.6.95, the cmake configuration step for the whole project fails. The most visible symptom is the inability to locate kdcraw (or at least, it finds it at first but the misplaces it later on.)

This seems to be caused by the use the raw DIGIKAMSC_USE_PRIVATE_KDEGRAPHICS in extra/CMakeLists.txt to determine whether or not to use the local library copies. However, this parameter is overlayed by ENABLE_PRIVATE_KDEGRAPHICS in the main CMakeLists.txt. Changing extra/CMakeLists.txt to use ENABLE_PRIVATE_KDEGRAPHICS allows successful completion of the cmake step.

(Although DIGIKAMSC_USE_PRIVATE_KDEGRAPHICS  is mentioned in the README file, the magic behavior change breaks the very instance it was supposed to protect.)
Comment 1 caulier.gilles 2013-03-15 14:32:43 UTC
Please try digiKam 3.1.0 where this problem have been fixed normaly...

Gilles Caulier
Comment 2 Sven Coenye 2013-03-19 22:09:16 UTC
3.1 indeed does not have the problem but only because DIGIKAMSC_USE_PRIVATE_KDEGRAPHICS now defaults to ON (yet the OPTION comment on the same line claims the default is OFF.) The problematic code is still there and triggers when someone on KDE < 4.7 specifies DIGIKAMSC_USE_PRIVATE_KDEGRAPHICS = OFF for whatever reason. 

I realize now my original suggestion would make it impossible to compile the extras separately. I'm not familiar enough with CMake to know if the following would violate use guidelines as Cmake itself has no problems with it: replace ENABLE_PRIVATE_KDEGRAPHICS with DIGIKAMSC_USE_PRIVATE_KDEGRAPHICS throughout in the upper level CMakeLists.txt and change the initial logic to force it ON if KDE < 4.6.95 is detected.
Comment 3 caulier.gilles 2013-11-27 13:05:15 UTC
This entry stil valid with digiKam 3.5.0 ?

Gilles Caulier
Comment 4 Sven Coenye 2013-12-03 02:58:51 UTC
This regressed back to the 2.9.0 situation:
DIGIKAMSC_USE_PRIVATE_KDEGRAPHICS is again OFF by default. Compilation against KDE < 4.6.95 will attempt to flag an override by setting ENABLE_PRIVATE_KDEGRAPHICS but extras/CMakeLists.txt only considers DIGIKAMSC_USE_PRIVATE_KDEGRAPHICS which remained OFF. As a result, it does not execute the ADD_DIRECTORY calls.

The simplest way out still looks to be to change the value of DIGIKAMSC_USE_PRIVATE_KDEGRAPHICS if needed and not use ENABLE_PRIVATE_KDEGRAPHICS at all. Would that violate any guidelines as it is a user supplied parameter?
Comment 5 caulier.gilles 2013-12-03 07:25:31 UTC
Git commit 8ad9de540a2d5a17e921527e3a5cb7c2c53065ae by Gilles Caulier.
Committed on 03/12/2013 at 07:23.
Pushed by cgilles into branch 'master'.

Fix compilation rules about local libkipi/libkexv2/libkdcraw to use, by checking right cmake variable set by root cmake script
FIXED-IN: 4.0.0

M  +2    -2    extra/CMakeLists.txt

http://commits.kde.org/scratch/mwiesweg/digikam-sc/8ad9de540a2d5a17e921527e3a5cb7c2c53065ae