What makes cmake variables important?

[Alexander Neundorf]

On Tuesday 18 September 2007 04:30, Oswald Buddenhagen wrote:
> On Mon, Sep 17, 2007 at 10:30:29PM -0400, Alexander Neundorf wrote:
> > > define_library(resolv dn_expand)
> >
> > A problem with this is that it is hard for somebody else to figure out
> > what's going on. So if you use e.g. SOCKET_LIBRARIES later on, it is not
> > possible to find where this variable is set by just searching for this
> > string in the cmake files, since the variable name is constructed via
> > string operations in the macro.
>
> well, yes. but if it is documented and used throughout, one can figure
> out quickly that he has to grep for "\(\s*libname\s".
> also, the macro could be "unautomated". the principle of having optional
> libs without lots of explicit if()s counts.

Well, OTOH having cmake complain if you don't handle a failure is also a good 
principle. 
Beside that it's no use to discuss that, the NOTFOUND is a significant feature 
of cmake and will not be changed, and we shouldn't try to work around it for 
whatever reasons. This would only introduce problems.

> on a completely different cmake matter ... how about
> SET(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS true) ?

I don't think we should make this the default for KDE (i.e. putting that in 
FindKDE4Internal.cmake or something like this) and I'd also say we shouldn't 
use it in kdelibs/, because it is too different and sometimes it is even 
helpful :-)
Actually I'd also like to not use it in kdepimlibs and kdebase, as the central 
kde modules.

This setting is directory-level, i.e. it is active in the current and all its 
subdirectories.

Bye
Alex