[CMake] An observation about CTest

[Convey, Christian J CIV NUWC NWPT]

Hi Eric,

Thanks for all those details.  I wasn't aware that CMake drew a distinction between macros and functions.  I'll try to have a look at the ML archives.

- Christian 

> -----Original Message-----
> From: Eric Noulard [mailto:eric.noulard at gmail.com] 
> Sent: Sunday, June 27, 2010 16:42
> To: Convey, Christian J CIV NUWC NWPT
> Cc: alokgovil at hotmail.com; cmake at cmake.org
> Subject: Re: [CMake] An observation about CTest
> 
> 2010/6/27 Convey, Christian J CIV NUWC NWPT 
> <christian.convey at navy.mil>:
> > I don't expect a lot of support for what I'm about to say, 
> but I think it's perhaps worth saying anyway...
> >
> > It seems like CMake's and CTest's have outgrown their 
> scripting languages.
> >
> > As far as I can tell, all CMake/CTest variables are either macro 
> > formal parameters, or variables in a single global 
> namespace.  I think 
> > one consequence of this is that macro invocations make their 
> > contributions primarily by modifying variables in the global 
> > namespace.  As people discovered in the 1970's and 1980's, the 
> > confusion caused by this approach (global variables) can be 
> so extensive that it's worthwhile to change coding pracices 
> (structured programming, etc.), and possibly to improve the 
> base language as well.
> 
> I think you should dive into the Mailing List archive because 
> there have been several valuable discussion about CMake 
> evolution including the "replacement/extension"
> of CMake scripting
> language with "full language" like Lua or Python.
> 
> > But even better would be enhancing the CMake scripting language to 
> > support local variables in macros, and possible package-scoped 
> > variables as well.  This clarifies the intended interface 
> that certain 
> > macro packages are intended to provide, because variables 
> intended as implementation details would be in a namespace 
> inaccessible to the script that invokes those macros.
> 
> CMake is offering scope from a parent/child point of view 
> including setting variable for your parent with set(xxxx 
> PARENT_SCOPE) this was indeed provided after lengthly ML discussion.
> 
> Concerning "local variables" you should have a look at the 
> difference between a "MACRO" and a "FUNCTION" this may 
> already gives you part of what you want.
> 
> Then as far as I can tell CMake scripting is no-where near a 
> "must not evolve" language many improvement has been put in 
> since I began to use CMake 2.2.x (can't remember X) even the 
> introduction of "POLICY" which each backward compatibility.
> 
> So I think you may not hope to have ALL what you require in 
> CMake after a message on this ML be you will certainly have 
> feedback and may be new feature if there is a consensus and 
> some proof of concept patch provided.
> 
> --
> Erk
> Membre de l'April - « promouvoir et défendre le logiciel 
> libre » - http://www.april.org
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5218 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100627/89350608/attachment-0001.bin>