[CMake] An observation about CTest

[Convey, Christian J CIV NUWC NWPT]

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.

It the CMake scripting language wouldn't be allowed to change, then I'd want to consider a change to CMake coding style:

Any macro invocation that's intended to update global state (for example, "INCLUDE_DIRECTORIES(foo)") should only be allowed to modify global-namespace variables that are explicitly named as parameters to the macro call.  For example:
"INCLUDE_DIRECTORIES("foo", MY_DIRECTORIES_LIST)".

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.

Another possiblity, which I'm sure has been considered, would be to stop having CMake and CTest provide their own scripting languages, and instead make them be libraries in some other, more advanced scripting language like Python.  

Anyway, that's just my two cents as someone who's been casually using CMake for the past two or three years.

- Christian




> Hi all,
> 
> I tend to agree to this observation in general about CMake 
> too.  I had to do a lot of reading and experimentation to 
> make it do what I wanted, even though at the end of the day, 
> the resulting CMakeList.txt file is very simple.
> 
> I do understand why this is so.  As can be seen by the type 
> of requests on this list and your responses to them, Cmake is 
> supporting a LOT of different types of projects and needs.
> 
> So while it won't be possible to reduce the number of 
> commands and variables, it would help to have better 
> documentation -- with examples for each command and variable, 
> examples for "typical" stuff people need, etc.  I had to 
> struggle even to do simple things like specifying custom 
> compiler and linker flags for Visual Studio and GCC.
> 
> Thanks and best regards - Alok
-------------- 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/e229dc11/attachment.bin>