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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
