RFC: replacing MacroLogFeature.cmake with FeatureSummary.cmake

[David Jarvie]

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