Automatic recording of required packages...

[Alexander Neundorf]

On Monday 01 November 2010, Christophe Giboudeaux wrote:
> Hi,
>
> Le 31/10/2010 13:40, Alexander Neundorf a écrit :
> > 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.
> >
> > Opinions ?
>
> That means cmake will stop running if it's unable to find a required
> package and repeat that for *every* missing required dependency.

Yes.

> So instead of having a nice summary with the missing required
> dependencies, we'd just see cmake hang. That surely is a regression and
> I still don't get why you don't like the macro_log_feature behaviour.

Because the following is regular valid cmake code:

------------8<---------------8<-------------8<------------
find_package(Foo REQUIRED)

add_executable(hello main.cpp)
target_link_libraries(hello ${FOO_LIBRARY})
------------8<---------------8<-------------8<------------


also the following is valid:

------------8<---------------8<-------------8<------------
find_package(Foo)

add_executable(hello main.cpp)
if (FOO_FOUND)
  target_link_libraries(hello ${FOO_LIBRARY})
endif()
------------8<---------------8<-------------8<------------


but the following is actually broken:

------------8<---------------8<-------------8<------------
find_package(Foo)

add_executable(hello main.cpp)
target_link_libraries(hello ${FOO_LIBRARY})
------------8<---------------8<-------------8<------------

Here cmake reports an error in target_link_libraries():


-- Could NOT find Foo  (missing:  FOO_LIBRARY)
CMake Error: The following variables are used in this project, but they are 
set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake 
files:
FOO_LIBRARY
    linked by target "hello" in directory /home/alex/src/tests/foo

-- Configuring incomplete, errors occurred!


I mean, basically none of our packages is marked as REQUIRED, and I'm not sure 
that really everywhere is checked that it has actually been found and dealt 
appropriately with that case.
The REQUIRED keyword is there to make sure you don't run into such trouble.
If you really need something, cmake stops processing there, so you can be sure 
whenever you get to cmake code which uses that required package, everything 
is there as exptected.
By not using the REQUIRED keyword we "risk" to get the error message you can 
see above instead of a message that tells you that find_package(Foo) failed.
I attached a small example.


Also, I'd like us to stay as close to normal cmake behaviour as possible, and 
to use as few own cmake modules as possible (...I know I know).
And the behaviour we are using with macro_log_feature() would never be 
accepted into upstream cmake. It works around the assumptions built into 
cmake.
If you use find_package(), and you really need it, use "REQUIRED".
Then internal variables are set, and other tools coming with cmake can make 
use of it (as e.g. FeatureSummary.cmake).
I would prefer if we use the normal cmake behaviour.
What we do now is just for laziness.
(I have the feeling that there are some similarities in this discussion to the 
current kdelibs-Qt discussion...)

Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.tar.gz
Type: application/x-tgz
Size: 467 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20101101/89ba2902/attachment.bin