RFC: replacing MacroLogFeature.cmake with FeatureSummary.cmake

[Alexander Neundorf]

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 ?

Alex