James Mansion wrote:
Ken Martin wrote:
other's variables out of the box. But with the Modules directory we either have to
have a copy of each module for every possible scripting language, on the fly
converters between any two scripting languages, or something like that to make it
work. Trying to figure out how to manage the mixed
Surely the idea is that modules should be self contained: they expose data by
registering it into the CMake core (possibly with callbacks) and interface to other
modules through the core. Modules can be in different languages without the issue you
indicate (or, the modularity is poor and the binding too tight).
Yes, this is the idea. All bindings only call C++ functions of
"CMakeCore", by this we only have a n-to-one problem.
And it looks like most stuff is to pass and parse long
const char* strings, a lists with separator ";".
For instance see the SET command in cmSetCommand.cxx:
// add the definition
this->Makefile->AddDefinition(variable, value.c_str());
The problem is how to handle SET(X ${Y} z). ${Y} is a list
for cmake script but only a string for other languages.
My first idea is to introduce a list class on the C++ side,
but I assume there are already myriads of solutions to
represents lists in C++, not only std::list.
Peter
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
