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 [EMAIL PROTECTED] _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem