Bill Hoffman wrote:
James Mansion wrote:
So, C++ is the language we picked/like. You are welcome to contribute
one in C++. Imagine if you could develop generators (I assume that is
what you mean by emitters) in any language! You wouldn't even be able
to share them.
Bill, I like C++ as much as anyone, but I also work in other languages.
What youu wrote above is such utter bullshit that its hard to credit.
If I have a project that is largely in a more convenient language -
whether Java or Python or C# (or even Lua) - and it has material
components in C++ for performance or reuse reasons, then it is clearly
reasonable to ship something that can make a good stab at building the
DLLs and running SWIG (and I think CMake reasonably can do this) *and*
to expect the target user base to have the runtime for the other
language concerned.
You are inventing this paranoid fantasy of a 'tower of babel' effect
poisoning the centrally maintained CMake. And that's just not justified.
Well, I suppose you don't have to use CMake. Perhaps scons would be a
better fit for your tastes.
In a Python-based system, yes.
But if I have a C++ code and a variety of value added components aimed
at different users, then I can hardly tell Java customers to use Scons,
any more than I could reasonably ask Python customers to use ant.
If you did use an arbitrary language bound to CMake core, people
building your project would have to build/get something different than
potentially any other CMake based project.
So? Is that a problem in *every* context?
Wow, now I need CMake, Ruby, Python, and Tcl just to build this set
of software. This is just the type of thing CMake was designed to avoid.
Then probably that is because those projects use Ruby AND Python AND Tcl
- so I have to have them anyway. Hey, lets all use C89. Everyone has
that, right?
I like CMake. But the language is impenetrable, verbose, and basically
poor - it can't quite decide whether to declaratve/functional or
imperative, has limited data type or structure support - or modularity
or reuse support. It has the appearence of something that had modest
objectives to start with and has evolved. That's quite natural, but
eventually you have to say 'Enough!'.
I like CMake for what it does, but not the way it does it. If you are
saying that compatibility with the naivety of the past when the macro
language was being used for less ambitious things then fine. But don't
expect that to stop us thinking that a) the language design sucks and b)
of all the alternatives, Lua would seem to be the best fit in terms of
its own dependencies and the cleanliness of the language itself.
James
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
