[CMake] An observation about CTest

[Eric Noulard]

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