Hi Ken,
2.Closing statements need and empty () [at least they don't need to
duplicate the expressions any more].
Technically I believe this is possible. It has been asked for in the past.
Just a change to the yacc IIRC. I tend to not mind () personally.
It has to be more or less as easy as that.
7.It has no functions (implemented in the script itself I meant) [macros
are
not the same]
2.6 has functions
Cool!
12.It has no scope.
Well directories have scope
Which is way too astreay for my taste.
One wonders: is there a file-level unit of scope? what are the rules? what
if I use "include" instead of "add_subdirectory". Can I load a module with
that same local scope?
IMO the "add_subdirectory" command is itself half-cooked, I would have
preferred a better thought out modules design.
and always have, now functions do as well. There
is no midstream push/pop scope ala "{" "}" but you can just make a
function.
Ya, that's not big deal.
There is also some object scope supported through the use of properties on
targets/source files/directories/tests/etc.
Which means that is some concept of "objects" in Cmake, but they are a bit
like those of old VB in the sense that the only objects are those hard coded
in the system.
16.Least but not least: the language is extensible but not in the user
side.
That is, I cannot *plugin* (entirely at the user side) my own "internal"
functions even though the underlying system is quite extensible.
You can define your own commands and even override the default commands
from
the script level.
Ya, but you need a special script command to invoke it,
I mean the hability to define actual commands because the underlying C++
framework is quite flexible.
You can also use the C plugin API to dynamically compile and load a run
time
plugin.
This one I didn't knew about.
We discourage this as it is more prone to errors (user running a
32bit CMake but building a 64 bit executable tries to dynamically load a
64
bit module into a running 32 bit cmake, etc, etc)
That should just blow up in the users face.. so he wil just go ahead and
correct it.
Again, trust the programmer :)
This could be fixed by
running the plugin in a separate process etc but I'm just not sure we
really
want to expose/encourage that low level of an API.
I don't think you need to do that, just let it break.
Best
--
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com
http://groups.google.com/group/cppba
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
