James Mansion wrote:
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.
Wow this thread is really getting out of hand! Please refrain from
swearing....
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.
I don't agree, having multiple language bindings for CMake would be a
mistake. As I have said perhaps two languages someday. But no more
than that.
.
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?
Overall, I think it would be bad.
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?
What if they only use the Ruby, and Python for the build system parts.
What if people want to share build system stuff wrapped in different
languages.
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 don't think I have to say Enough. It has evolved, and built some
pretty impressive stuff. I am not completely happy with it, but it
works. I also don't think dropping support for it is an option.
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.
OK, now you are talking about one language again. I was trying to say
that having a swig like any language support was bad. I am also saying
that we will support the current language as long as there is a CMake.
We may or may not add Lua. But, I don't think we will be providing a
swig style java, c#, Lua, python, tcl language binding to the CMake make
generation system. I also feel pretty confident that the core
generation system will stay in C++.
So, a summary seems in order in hopes of getting this discussion back on
track.
1. CMake may add support for an additional language. Right now Lua
seems to be the best candidate for that. It is small and easy to embed.
The Lua stuff would have to work well/exist with the current CMake
language. I am still not convinced about this, but it is an option.
2. It does not make sense to use SWIG to open up bindings to any
arbitrary language for CMake. There should be one binary the CMake
users can download/install to build any project that uses CMake as a
build system. It should not depend on any outside stuff. It should
require a C/C++ compiler to build.
-Bill
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
