Digikam/CMake Documentation(Frameworks)
Introduction
CMake configuration files were rewritten by Veaceslav Munteanu <veaceslav dot munteanu90 at gmail dot com> at 10 June 2014. The aim of new configuration was to reduce the linking overhead and improve CPU utilization while still keeping the modular design implemented by Teemu Rytilahti
CMake Structure
Independent Cmake configuration is presents in following folders:
- digikam-software-compilation
- core
- extra
- docs
The rewrite touched mostly the core folder.
CMake executables for core
Core cmake will link the following executable:
- digikam
- showfoto
- digikam database server - if compilation is enabled in cmake files
- various test executables - if testing is enabled
each of them depend on various sources which must be compiled before.
Folder structure
Sources are still not completely modular, but still follows this structure:
- core/app - digikamgui components - used in digikam main app
- core/libs - digikamcore components
- core/libs/database - digikamdatabase shared library components + digikam gui sources
- core/utilities - digikam main executable components
- core/imageplugins - image plugins shared libraries
- core/showfoto - showfoto sources for showfoto executable
CMake Implementation Details
Include directories
Local include directories are all managed by this snippet of code:
set(DK_INCLUDES_ALL "")
HEADER_DIRECTORIES(DK_LOCAL_INCLUDES_RAW)
# This macro will set all paths which do not containt libjpeg-
# We will add later the directory we need
FOREACH(var ${DK_LOCAL_INCLUDES_RAW})
STRING(REGEX MATCH "libjpeg-" item ${var})
IF(item STREQUAL "")
LIST(APPEND DK_LOCAL_INCLUDES ${var})
ENDIF(item)
ENDFOREACH(var)
set(DK_LOCAL_INCLUDES ${DK_LOCAL_INCLUDES}
libs/jpegutils/${DIGIKAM_LIBJPEG_DIR})
include_directories(${DK_LOCAL_INCLUDES})
There is no need for manual intervention, even if you add a new folder, just keep in mind to use:
#include "tagmngrlistitem.h"
instead of :
#include "models/tagmngrlistitem.h"
To avoid linking overhead and make a better use of sources there are some dynamic libs.
- digikamcore - core components used by almost all executables
- digikamdatabase - database components, also used together with digikamcore
- imageplugins - image plugin implementation - soon to be deprecated
- kio modules - soon to be deprecated
Static Libraries
Currently cmake configuration features 4 shared libs:
- queuemanager
- advancedrename
- importui
- baloowrap
This libs are linked in digikam main executable and some tests
Object Libraries
While static libraries are still collection of objects, CMake offer a better approach by allowing to specify an OBJECT library:
set(libslideshow_SRCS
slidetoolbar.cpp
slideosd.cpp
slideproperties.cpp
slideimage.cpp
slideerror.cpp
slideend.cpp
slideshow.cpp
slidehelp.cpp
slideshowsettings.cpp
)
add_library(slideshow_src OBJECT ${libslideshow_SRCS})
OBJECT library is a cmake internal implementation feature and allow to easily manage sources. Here is an example of how to make a shared lib using OBJECT libraries:
add_library(digikamcore
SHARED
$<TARGET_OBJECTS:slideshow_src> # the lib we made few lines above
$<TARGET_OBJECTS:digikamdatabasecore_src>
$<TARGET_OBJECTS:dimg_src>
....
)
Final Words
Remember |
---|
Please follow the guidelines when adding sources to CMakeFiles:
|