[CMake] Code and API review request for Qt5 CMake files

[Alexander Neundorf]

On Friday 09 March 2012, Michael Hertling wrote:
> On 03/05/2012 02:04 AM, Stephen Kelly wrote:
...
> > I don't actually see the problem with checking Qt5_XYZ_FOUND. Unset
> > variables are well defined as false in the if() command. Maybe I
> > misunderstand you?
> 
> Maybe. ;-) What ensures the variables had already been unset before
> FIND_PACKAGE() was invoked? If they had evaluated as TRUE - for what-
> ever reason - and FIND_PACKAGE() fails to load Qt5Config.cmake, they
> will still be TRUE afterwards although Qt5 has not been found at all.
> 
> IMO, if FIND_PACKAGE() fails to locate a package, one shouldn't rely
> on the assumption that any variable except *_FOUND has a reasonable
> value. Thus, in order to play safe, one should access the variables
> only after checking the package's successful detection, 

Yes, exactly :-)
(...which would be the case with the "set _FOUND only TRUE if all components 
have been found).

> e.g. like:
> 
> IF(Qt5_FOUND AND Qt5_Xml_FOUND)

See the other thread
With a potential OPTIONAL_COMPONENTS parameters you could do:

find_package(Qt5 COMPONENTS QtXml)
and checking Qt5_FOUND would be enough.

If you do 
find_package(Qt5 COMPONENTS QtXml OPTIONAL_COMPONENTS QtFoo)
you would have to check both Qt5_FOUND and Qt5_QtFoo_FOUND.

 
> This consideration is one of my major objections against the proposal
> w.r.t. permitting config files to set *_FOUND by themselves. 

Here I object.
This is necessary.
Let's say one Config file depends on another one and does
find_package(TheOtherPackage NO_MODULE)

If TheOtherPackage is not found, it must be possible for the calling Config 
file to indicate that, although the Config file has been found, the package is 
not usable. because its dependencies have not been found.


...
> Do you mean {FindQt5,Qt5Config}.cmake as a wrapper around multiple
> FIND_PACKAGE(Qt5xyz ...) invocations that concatenates the several
> Qt5xyz_LIBRARIES to yield the final Qt5_LIBRARIES, e.g.? If so, a
> possible objection that comes to my mind is that
> 
> FIND_PACKAGE(Qt5 COMPONENTS Gui Xml Svg)
> 
> ends up with Qt5Gui twice and Qt5Core four times in Qt5_LIBRARIES.
> Something similar holds for -D/-I unless {FindQt5,Qt5Config}.cmake
> sorts it out. This prolongs link times - although I don't know if
> significantly or negligibly - and might be an issue w.r.t. to the
> maximal command line length. Once more, just spontaneous thoughts,
> nothing definitive. In general, however, it's easier for a, say,
> integral {FindQt5,Qt5Config}.cmake to provide optimal results.
> 
> What I actually meant with regard to a FindQt5.cmake shipped with
> CMake: This would need to cope with several Qt5 installations, and
> these might be quite different, think of cross compiling issues. In
> contrast, a Qt5Config.cmake is part of the respective installation
> and must cope only with the latter. Thus, it is potentially less
> complicated than a FindQt5.cmake would need to be.

Side note to Stephen: this is the same as what I am always talking about on 
kde-frameworks-devel wrt. whether KDE frameworks will be just a set of 
independent libraries to somewhat more integrated.

Alex