[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: RFC: replacing MacroLogFeature.cmake with FeatureSummary.cmake
From:       David Jarvie <djarvie () kde ! org>
Date:       2011-07-17 23:43:57
Message-ID: 201107180044.04656.djarvie () kde ! org
[Download RAW message or body]

On Wednesday 13 July 2011 20:16:58 Alexander Neundorf wrote:
> Hi,
> 
> in KDE we have the file MacroLogFeature.cmake which we use to print a summary 
> of found/missing packages at the end of a cmake run.
> I added similar functionality later on in 2007 to cmake in the form of 
> FeatureSummary.cmake:
> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:FeatureSummary
> 
> Among others due to source compatibility requirements we are still using 
> MacroLogFeature.cmake in KDE, but I'd like to get rid of this and instead use 
> FeatureSummary.cmake from the not yet existing cmake 2.8.6, which means we 
> have some time to improve it so it does what we need.
> The plan is to get this into cmake 2.8.6, so once we have the binary break 
> (and minor source compat. break) with Qt5 and KDE frameworks, to make the 
> switch here too.
> 
> -------------------------
> What is missing in FeatureSummary.cmake compared to MacroLogFeature.cmake:
> -------------------------
> 
> * the REQUIRED keyword, to make the cmake run error out at the end if one of 
> the packages marked with this keyword have not been found
> 
> -------------------------
> What has FeatureSummary.cmake that MacroLogFeature.cmake does not have:
> -------------------------
> * more flexible output, to a file, to stdout
> * should be faster, since it stores the results in a cmake property and not in 
> a file (cmake properties did not exist back then when I write 
> MacroLogFeature.cmake initially)
> * it can separate between "packages" and "features", i.e. you can also add 
> feature documentation to the log at the end, e.g. for enabled or disabled 
> options
> * it's in cmake, so no extra stuff for us to maintain
> 
> 
> -------------------------
> What I'd like to have additionally in FeatureSummary.cmake
> -------------------------
> 
> * the ability to report "runtime" dependencies, i.e. packages which have been 
> checked for at build time, but which are actually not used at build time, but 
> only at runtime. So the build will be successful if they are missing, but the 
> result will not run properly
> 
> * the ability to set not only a description of a package, but also one or more 
> usages/purposes.
> 
> How I imagine this is the following, e.g. for FindLibXml2.cmake:
> 
> inside FindLibXml2.cmake:
> find_path(...)
> find_library(...)
> ...
> set_package_info(LibXml2 "XML processing library." "http://xmlsoft.org/")
> 
> 
> and then in a project using LibXml2, let's assume koffice:
> 
> find_package(LibXml2)
> 
> set_package_properties(LibXml2 PROPERTIES
> PURPOSE "Required for exporting spreadsheets to odt format in kspread")
> 
> 
> and in some other part of the project:
> set_package_properties(LibXml2 PROPERTIES
> PURPOSE "Required for importing html files in kword")
> 
> 
> find_package(DBus)
> set_package_properties(DBus PROPERTIES TYPE RUNTIME
> PURPOSE "Required to disable the screensaver via kpresenter")
> 
> -------------
> 
> which should then produce something like:
> 
> -- Found packages:
> LibXml2, XML processing library., <http://xmlsoft.org>
> * Required for exporting spreadsheets to odt format in kspread
> * Required for importing html files in kword
> ...
> -- Missing RUNTIME packages:
> DBus, A desktop IPC bus, <http://dbus.freedesktop.org>
> * Required to disable the screensaver via kpresenter
> 
> 
> 
> What do you think of this ?
> More wishes ?
> Should it do it in a different way ?

Something else which would be useful would be to output the actual file names \
(library files, header files etc.) which were checked for but not found when looking \
for the missing packages. Trying to determine which distro package to install to \
satisfy the dependency isn't always straightforward, since distro package names \
aren't always the same as the cmake package names. In these cases, I quite often have \
to find the cmake module used to locate the package, and then look through the cmake \
module to work out the files it's looking for, in order to then be able to do a \
package search for my distro to find which package to install. 

-- 
David Jarvie.
KDE developer.
KAlarm author -- http://www.astrojar.org.uk/kalarm


[prev in list] [next in list] [prev in thread] [next in thread]