Calling FindQt4 and FindKDE4 multiple times

David Faure faure at kde.org
Fri Oct 5 20:24:57 CEST 2007


On Friday 05 October 2007, Alexander Neundorf wrote:
> On Thursday 04 October 2007 15:28, David Faure wrote:
> > What do you think about this patch?
> > It reduces the debug output (and the time, a little bit) when configuring
> > extragear from the toplevel. Because it's possible to configure it globally
> > or each subdir separately, each subdir calls find_package(KDE4 REQUIRED) so
> > the output looks like a large mess with the multiple lines of output
> > related "looking for Qt4" and "looking for KDE4" repeated 9 times.
> >
> > KDE4_FOUND and QT4_FOUND don't go into the cache, so I think this change is
> > correct, it only makes a difference when find_package is done multiple
> > times. (Maybe cmake itself could remember the packages called, and notice
> > "OK I have done find_package(KDE4 REQUIRED) already once, no need to do it
> > again"?)
> 
> 
> Hmm, not sure.
> 
> E.g. in FindQt4.cmake there is a QT_MIN_VERSION, where the user can adjust the 
> required version of Qt4.
> 
> So e.g. toplevel could do:
> 
> set(QT_MIN_VERSION 4.0.0)
> 
> while in some other subdir 
> set(QT_MIN_VERSION 4.3.0) 
> might be used.

OK I guess it's easy enough to double check the min version even in the "already did that" branch.

> The same for the arguments like "REQUIRED", the subcomponents etc., so all 
> this needs to be handled by the patch. FindQt4.cmake is already complicated 
> enough.

Well.. if we know we have found Qt already, it doesn't matter if it's now required or
optional for the current caller, we found it anyway :)

subcomponents isn't a feature we use in KDE (kdelibs needs all main subcomponents
already ;) and this doesn't apply to FindKDE4Internal.cmake anyway.

> So the patch will work in the common case but has the potential to break 
> stuff. Is the optimization measurable ?
> If it's not significant I'd say due to the potential to break stuff this 
> should not be committed.

This isn't really about speed, it's mostly about being able to read the output.
It took me a loong time to spot the IMLIB_DIR error message in the HUGE output
from configuring extragear. (I wish cmake would stop at such error messages
instead of going on, btw...)

Please compare the attached files. My patch reduces by HALF the amount of output
when configuring extragear as a whole. It might need improvement, but there -is-
a need for this.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: orig_output
Type: application/octet-stream
Size: 15798 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20071005/a11fe573/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: with_patch
Type: application/octet-stream
Size: 8977 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20071005/a11fe573/attachment-0003.obj 


More information about the Kde-buildsystem mailing list