Brandon Van Every escreveu:

I'm not willing to concede the clarity.  As I just wrote, "backwards
compatibility" is an issue to solve, not a dealbreaker.  As for labor,
there's already a quorum of people interested in the issue, and CMake
forks have been threatened before.  I'd like to see people identify

When I meant *fork* I didn't mean to threaten anyone. It's just a viable option that doesn't depend on Kitware. Now, to argue the problem of 'backwards compatibility', first we have to decide if changing to Lua is really needed. That's where our homework begins. At first, I'd like to change because I know Lua and is not cryptic (as, for instance, jam is for me). But that don't suffice. For what you've told, you might have more experience with build system needs, as you are working on porting a autotools build to cmake.

actual strategic needs - things that matter for the next 5..10 years.
I'd like to see people consider the validity of numerous complaints
about the CMake language, before shutting down conversation about it.
I'd like to see people try the CMake scoping and function improvements
that were recently made in CVS.  I'd like to see people examine other
build systems and return with tangibles, i.e. "this is clearly better"
rather than "I think it would be better."

Agreed, although as I said, what bothers me the most is cmake's syntax, and I think that's not gonna change in near future.

I agree that Kitware hasn't been persuaded of the value of using a 3rd
party open source language.  But why should we stop investigating at
their say-so?

Sure, we can do whatever we want, EXCEPT trying to push Lua into CMake. I don't think it's fair with kitware because they're supporting an open source project, donating their work time to something that everyone can have profit, the least we can do is respect their position.

Regards,
rod

_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to