KDE/kdelibs/cmake/modules

[David Faure]

On Tue, Apr 18, 2006 at 09:59:13PM +0200, Alexander Neundorf wrote:
> Hi David,
> 
> On Tuesday 18 April 2006 14:22, Matt Rogers wrote:
> > On Tuesday 18 April 2006 06:22, David Faure wrote:
> > > SVN commit 531000 by dfaure:
> > >
> > > More use of the cache; fixing previous commit to not recheck everytime
> > > when something isn't available (e.g. agg for me).
> >
> > is there a way we can make it check if we've installed something that
> > wasn't available before?
> 
> I'm not sure your fix is the best way.
> AFAIK the cache works like this:
> if a FIND_XXX() call is executed, the result if stored in the cache. If it 
> succeeded, it will be "/usr/local/lib/libfoo.so" or something, if it failed 
> it will be "foo-NOTFOUND".
> When the FIND_XXX() command is executed the next time, the cache will be 
> checked. If the value is "*_NOTFOUND", the check will be executed again. This 
> is intentional, so that after installing a missing component it will be found 
> automatically.
> 
> Do these checks actually consume a measurable amount of time ?

Hmm. OK, maybe I went a bit over-board with the CACHED variables. When the configure
check is only about calling FIND_XX, then you are probably right, no point in short-circuiting it.

But for FindGSSAPI, FindAkode, FindXmms, and all the checks using PKGCONFIG,
those checks would re-run an external program everytime (krb5-config, akode-config, xmms-config, or pkgconfig),
which has to take time. The way I saw that it was launching those programs every time
is that I have this debug output in cmake (was there for other reasons, initially ;)

--- cmExecProgramCommand.cxx    15 Mar 2006 16:02:01 -0000      1.21
+++ cmExecProgramCommand.cxx    18 Apr 2006 20:30:45 -0000
@@ -104,6 +104,7 @@ bool cmExecProgramCommand::InitialPass(s
   int retVal = 0;
   std::string output;
   bool result = true;
+  std::cerr << "Executing command " << command << std::endl;
   if(args.size() - count == 2)
     {
     cmSystemTools::MakeDirectory(args[1].c_str());

So I'm OK with reverting CACHED_FOO when the test is only about using FIND_XXX,
but I think my changes still make sense for many checks.

Or should PKGCONFIG() itself use the cache more aggressively?

--
David Faure
faure at kde.org