Automatic recording of required packages...
Alexander Neundorf
neundorf at kde.org
Sun Oct 31 19:45:15 CET 2010
On Sunday 31 October 2010, Allen Winter wrote:
> On Sunday 31 October 2010 8:40:39 am Alexander Neundorf wrote:
> > Hi,
> >
> > the upcoming 2.8.3 release of cmake (_please_ test the rc4) will have an
> > improved logging for find_package() calls.
> > Together with the enhanced FeatureSummary.cmake module of cmake 2.8.3 it
> > can produce a text file which contains which packages where found and
> > which were not found for each find_package() call in a project, no
> > further work required (except one call to feature_summary() at the end of
> > the toplevel CMakeLists.txt
> >
> > This is already supported in MacroLogFeature.cmake in kdelibs.
> > The result of this is a file ${CMAKE_BINARY_DIR}/FindPackageLog.txt, I
> > attached such a file (FindPackageLog.txt) from one of my builds.
> >
> > If you look at this file, you may notice that in the list of packages
> > which have been found it is not recorded whether the package was optional
> > or required.
> >
> > So I enhanced this a bit more, which resulted in
> > FindPackageLog.txt-required. Maybe you see the problem, basically all
> > packages are listed as "OPTIONAL", while I guess not all of them are
> > optional.
> > The problem is our macro macro_log_feature(), or more to the point
> > the "REQUIRED" argument for macro_log_feature().
> > This is how we use that:
> >
> > find_package(ZLIB)
> > macro_log_feature(ZLIB_FOUND
> > "ZLib"
> > "The Zlib compression library"
> > "http://www.zlib.net"
> > TRUE
> > ""
> > "Required by the core KDE libraries and some critical
> > kioslaves.")
> >
> > Here this argument is set to TRUE.
> > So also if ZLIB has not been found, cmake processing continues, and if at
> > the end some packages which were marked this way as "REQUIRED" have not
> > been found, an according error message is printed and cmake exits with an
> > error.
> >
> > This has two problem: cmake processing continues, while some variables
> > which are expected to be set (e.g. ZLIB_INCLUDE_DIR) are used in
> > CMakeLists.txt expecting that they are set to a valid location since ZLIB
> > is REQUIRED, but they are not. Same for library or other variables. This
> > can cause other cmake errors.
> >
> > The second problem is what you see in FindPackageLog.txt-required .
> > Basically all our packages are listed as OPTIONAL there.
> >
> > I never liked this "REQUIRED" argument for macro_log_package(), and now I
> > like it even less.
> > We tried to outsmart/work around cmake behaviour instead of going for a
> > proper solution.
> >
> > So, where am I going with this...
> >
> > I think I'd like to propose that macro_log_feature() ignores the REQUIRED
> > keyword (we can't simply remove it due to compatibility reasons) and that
> > we use REQUIRED in the find_package() calls instead.
> >
> > Pros:
> > - correct listing of all found and not-found packages by
> > FeatureSummary.cmake - cmake stops processing when something is REQUIRED
> > has not been found
> >
> > Cons: no summary of multiple missing required packages at the end of the
> > cmake run, only the last missing REQUIRED dependency will be printed.
>
> There is another con, the one that always irked me:
>
> if we have find_package(foo REQUIRED) and foo isn't found, then we do not
> see the nice message telling us what foo is and how to get it and why it is
> needed.
That's what I meant actually.
> So that's why i like the ZLIB feature discovery done like it is.
> But if your proposal solves this, then I have no objections.
>
> Bottom line: if a required package is not found, then we still should see
> nice user messages.
Do you know the FeatureSummary.cmake module coming with cmake ?
It has similar features to our MacroLogFeature.cmake (I implemented it after
we had some experience with MacroLogFeature in KDE).
The intention is/was that the Find-modules should set that information, e.g.
FindZLIB.cmake itself should have a line like
set_package_info(LibZLIB "ZLIB compression library." "http://www.zlib.net")
Then a call to feature_summary()
in the toplevel CMakeLists.txt will print the information (I added this
already to our macro_display_feature_log().
So, if a module sets this information (currently none does that), then it
should be possible that find_package_handle_standard_args() also prints that
information in case of failure for that package.
How does that sound ?
What it would need would be somebody who takes the effort to go through the
find-modules in kdelibs/cmake/modules/ and in cmake and add the calls to
set_package_info() there. This has just become easier now that cmake switched
to git :-)
Alex
More information about the Kde-buildsystem
mailing list